Se voce e novo no desenvolvimento em nuvem, "arquitetura orientada a eventos" pode soar como jargao tecnico. Mas na verdade e um conceito que voce ja usa no seu dia a dia. Quando voce pede um cafe numa cafeteria, o barista comeca a prepara-lo e voce e livre para fazer outras coisas enquanto espera. Isso e exatamente a arquitetura orientada a eventos: quando um "evento" (como um pedido) acontece, os servicos relacionados cada um reage por conta propria.
Monolitico vs Microsservicos
Vamos comecar entendendo por que esse tipo de estrutura e necessaria.
No passado, era comum colocar todas as funcionalidades em um unico programa gigante (monolitico). Para uma loja online, isso significa que o login, a busca de produtos, o pagamento e o rastreamento de entrega vivem todos dentro de um unico codigo. O problema e que corrigir mesmo uma pequena parte — por exemplo, a funcao de pagamento — exige reimplantar o sistema inteiro. E como ter que esvaziar um edificio inteiro para consertar apenas um quarto.
Os microsservicos resolvem esse problema. Login, pagamento e entrega sao separados em servicos independentes e pequenos. Se o servico de pagamento tiver um problema, o login e a busca de produtos continuam funcionando normalmente. Pense nisso como um condominio de apartamentos onde cada edificio opera de forma independente.
Acoplamento — Como os servicos se conectam entre si
Depois de dividir seu sistema em varios servicos, a forma como eles se conectam entre si importa enormemente.
O acoplamento forte (Tight Coupling) e como o servico A ligando diretamente para o servico B por telefone. Se B nao atender (cair), A nao consegue fazer absolutamente nada.
O acoplamento fraco (Loose Coupling) e como A deixando um recado numa caixa de correio para B pegar e processar depois. Mesmo que B esteja temporariamente ausente (fora do ar), A pode continuar deixando recados, e quando B voltar, ele os processa em ordem. Na AWS, o SQS (Simple Queue Service) faz o papel dessa caixa de correio.
Processamento Sincrono vs Assincrono
Sincrono significa que voce pede o cafe e fica de pe no balcao esperando ate ficar pronto. Chamar o Lambda diretamente pelo API Gateway e esperar uma resposta e um exemplo classico.
Assincrono e como pedir pelo aplicativo do cafe, sentar para trabalhar em outra coisa e ir ao balcao somente quando o seu vibrador tocar. Quando o Lambda e acionado via SNS ou SQS, a chamada retorna imediatamente e os resultados sao verificados depois.
Os padroes assincronos oferecem tres vantagens principais. Primeiro, lidam com grandes volumes de solicitacoes simultaneas (escalabilidade). Segundo, uma falha em uma parte nao paralisa todo o sistema (tolerancia a falhas). Terceiro, cada servico funciona de forma independente sem interferir nos outros (independencia).
Padroes-chave
Fan-out
Pense nisso como uma transmissao de radio. Um evento e entregue a varios servicos ao mesmo tempo. Por exemplo, quando um novo pedido chega, o servico de estoque, o servico de pagamento e o servico de notificacoes recebem a noticia simultaneamente e agem em consequencia.
Na AWS, um topico SNS atua como a emissora de radio, e cada fila SQS atua como assinante. O padrao de conectar um topico SNS a multiplas filas SQS — o fan-out SNS + SQS — e o padrao mais avaliado no DVA-C02.
Orquestracao vs Coreografia
A orquestracao funciona como um regente de orquestra — uma autoridade central diz "iniciar servico 1, depois que terminar, iniciar servico 2" e controla todo o fluxo. O AWS Step Functions desempenha esse papel. Ele permite gerenciar fluxos de trabalho complexos de forma visual e rastrear o sucesso ou falha de cada etapa.
A coreografia e como um flash mob. Quando a musica comeca (um evento e disparado), cada participante executa seu movimento designado. Nao ha regente central; cada servico ve o evento e responde por conta propria. O AWS EventBridge serve como esse barramento de eventos.
!Orquestração vs coreografia
Step Functions em detalhe
Step Functions e um servico de fluxo de trabalho que conecta multiplas funcoes Lambda ou servicos AWS em sequencia. Ha dois tipos dependendo de como sao executados.
O tipo Standard pode ser executado por ate um ano e mantém um log de auditoria completo de cada execucao. E adequado para processos de negocio importantes.
O tipo Express e executado por ate cinco minutos, e extremamente rapido e custa menos. E usado quando se processam centenas de milhares de eventos curtos por segundo.
Os tipos de estado incluem Task (executa trabalho), Choice (ramificacao condicional), Parallel (processamento paralelo), Wait (introduz um atraso), Map (processa arrays), e Succeed e Fail.
Pontos-chave para o exame
"Um evento para multiplos servicos simultaneamente" -- SNS fan-out
"Gestao central do fluxo de trabalho" -- Step Functions (orquestracao)
"Servicos reagem independentemente a eventos" -- Coreografia (EventBridge)
"Falha do servico B nao afeta A" -- Acoplamento fraco (usar SQS)
"Componentes que nao armazenam estado" -- Design stateless
"Solicitacao e retorno imediato, resultados depois" -- Padrao assincrono
"Execucao curta, alto throughput" -- Step Functions Express
SNS + SQS fan-out = padrao mais frequente no DVA-C02