Coordenando serviços e gerenciando estado

Desenvolvendo Aplicações na AWS

Ricardo Sueiras

Principal Technologist

Coordenação de serviços

 

• Vários serviços precisam trabalhar juntos para concluir um fluxo.
• Eles precisam de uma estratégia de coordenação.
• Duas abordagens: orquestração e coreografia.

Orquestração

 

• Um orquestrador central coordena o fluxo.
• O orquestrador define a sequência e decide qual serviço roda em seguida.
• Útil para novas tentativas, lógica condicional e tratamento de erros.
• Na AWS: implementado com Step Functions entre Lambda, ECS, DynamoDB.

Orquestração

 

• A lógica do fluxo fica em um único lugar, facilitando depuração e monitoramento.
• Trade-off: introduz uma dependência central.

Coreografia

• Sem controlador central.
• Serviços reagem a eventos de forma independente.
• Cada serviço escuta eventos relevantes e faz seu trabalho.
• Nenhum serviço precisa conhecer todo o fluxo.
• Melhora o baixo acoplamento e a escalabilidade.

 

Coreografia

• Na AWS: EventBridge, SNS, SQS.
• Altamente escalável.
• Trade-off: fica mais difícil entender e depurar conforme o fluxo cresce.

 

Arquitetura orientada a eventos

• Serviços se comunicam produzindo e consumindo eventos.
• Promove baixo acoplamento entre serviços.
• Promove alta escalabilidade.
• Permite processamento paralelo de eventos.
• Novos serviços podem assinar sem alterar os existentes.

 

Arquitetura orientada a eventos

 

• Trade-offs ao implementar EDA:
• Projetar para consistência eventual.
• Implementar idempotência.
• Tratamento de falhas é mais complexo.

Idempotência

 

• A mesma operação executada várias vezes produz o mesmo resultado.
• Princípio crítico em sistemas assíncronos e orientados a eventos.
• Sistemas distribuídos podem entregar eventos duplicados (retries, falhas de rede, reprocessamento).
• Preserva a correção e a confiabilidade do sistema.

Filas de dead letter

 

• Gerencia falhas na comunicação assíncrona.
• Isole mensagens problemáticas "venenosas".
• Após repetidas falhas de nova tentativa, a mensagem vai para a DLQ.
• O fluxo principal segue rodando.

Filas de dead letter

• Use quando a ordem das mensagens não é crítica.
• Evite em sistemas não críticos onde perda ocasional de dados é aceitável.
• Evite quando a ordem das mensagens deve ser preservada.

 

Gerenciando estado

• Gerenciar estado é fundamental para apps cloud native.
• Estado é qualquer dado preservado entre interações.
• Guardar estado localmente no servidor limita escalabilidade e resiliência.

 

Gerenciando estado

• O gerenciamento de estado envolve trade-offs conforme o que você constrói.
• Estado externo melhora escalabilidade e resiliência.
• Custos: latência e complexidade extras.
• Considere: consistência, cache e padrões de acesso a dados.

 

Stateful

 

• Dados de sessão ficam no servidor.
• Requisições devem ir para a mesma instância (sticky sessions).
• Limita a flexibilidade de escala.
• Se a instância falha, a sessão se perde.

Stateless

 

• Cada requisição é tratada de forma independente.
• Nenhum estado é armazenado no servidor.
• O estado vive em sistemas externos.
• Abordagem preferida para apps cloud native.
• Qualquer instância pode atender qualquer requisição, facilitando escala horizontal.

Vamos praticar!

Desenvolvendo Aplicações na AWS