01 - STAKEHOLDER (quem valida e esclarece):
02 - PROBLEMA (cenário e/ou dor):

Enfrentamos no dia 04/fev, instabilidades no ES, impactando nossa API da Carol. Identificamos que isso ocorreu, pois foram feitas várias chamadas de PUT no schema, gerando tasks de notify schema e sobrecarregando o ES.

• A instabilidade começou por volta das 16:35. Foi identificado um grande volume de chamadas simultâneas de PUT mapping, possivelmente disparadas por automação do SmartLink ao tentar atualizar esquemas de tabelas.

• Novas colunas começaram a ser enviadas a partir de tabelas do Protheus para o SmartLink, que por sua vez acionou a atualização de schemas no ES para muitas tenants. Isso gerou um volume alto de requisições, levando à instabilidade.

• Mesmo quando a API retornava erro 500, o MDM ainda tentava executar PUT mapping no ES. Além disso, a repetição dessas chamadas em loop agravou a sobrecarga.

• O ambiente foi estabilizado ao remover o ES do load balancer, interrompendo temporariamente as requisições.

Para mais detalhes acesse a thread.

03 - OBJETIVO (solução proposta):

• Implementar estratégia de circuit breaker para evitar que o MDM continue enviando requests de PUT mappings para o ES em casos de erros.

04 - QUEM PODE USAR (perfis de usuários):
05 - ASSETS (links e arquivos relevantes):
06 - CRITÉRIOS DE ACEITE:

• Entender porque estamos efetuando gravação do schema no ES (put mapping), sendo que este recurso já foi inativado a um certo tempo (por volta de 2023).

• Detecção automática da degradação do ES ou PG pelo mdm, diminuindo a vazão de requests (rate limit) para o banco de dados (ES ou PG), com objetivo de evitar a queda total e permitindo a plataforma se recuperar.