Arquitetura Orientada a Eventos
Gabarito: letra B. A prática fundamental de arquiteturas event-driven para garantir resiliência e escalabilidade é utilizar um message broker (fila intermediária) que desacopla produtores e consumidores, permitindo comunicação assíncrona e tolerância a falhas. Esse padrão é central no estilo Pub/Sub e Event Stream, conforme descrito nos fundamentos de arquitetura de software.
A banca testa o conhecimento do princípio de desacoplamento em arquiteturas orientadas a eventos. A alternativa correta é a única que descreve corretamente esse mecanismo.
Alternativa | Descrição | Correta? | Justificativa |
|---|
A | Estabelecer comunicação síncrona entre produtores e consumidores para garantir a entrega imediata de eventos. | ❌ Incorreta | Comunicação síncrona cria acoplamento forte, reduzindo resiliência e escalabilidade. |
B | Utilizar uma fila intermediária (message broker) para desacoplar produtores e consumidores. | ✅ Correta (GABARITO) | Desacopla componentes, permite comunicação assíncrona, tolerância a falhas e escalabilidade horizontal. |
C | Configurar consumidores para processar eventos duplicados exatamente uma vez, sem suporte a idempotência. | ❌ Incorreta | Eventos podem ser entregues mais de uma vez; idempotência é necessária para evitar inconsistências. |
D | Garantir que apenas um consumidor possa receber e processar cada evento, para evitar inconsistências nos dados. | ❌ Incorreta | Restringe o modelo pub/sub, limita escalabilidade e resiliência, criando gargalo único. |
E | Adotar a entrega de eventos no modo “fire-and-forget” sem qualquer mecanismo de confirmação ou retry. | ❌ Incorreta | Ausência de confirmação ou retry compromete a confiabilidade e a garantia de entrega. |
Alternativa A — ❌ Incorreta
Estabelecer comunicação síncrona prende o produtor ao consumidor, criando acoplamento forte. Isso reduz a resiliência (falha de um afeta o outro) e a escalabilidade (produtor precisa esperar o processamento). Em arquiteturas event-driven, a comunicação é tipicamente assíncrona.
Alternativa B — ✅ Correta ⟵ GABARITO
Utilizar uma fila intermediária (message broker) desacopla produtores e consumidores. O produtor publica eventos no broker sem conhecer os consumidores; os consumidores recebem de forma independente. Isso permite que um componente falhe sem derrubar o sistema, além de possibilitar escalabilidade horizontal. É a prática mais essencial do estilo event-driven.
Alternativa C — ❌ Incorreta
Afirma que consumidores devem processar eventos duplicados "exatamente uma vez, sem suporte a idempotência". Na prática, eventos podem ser entregues mais de uma vez (at-least-once). Para lidar com duplicatas, é crucial implementar idempotência – ou seja, processar o mesmo evento múltiplas vezes sem efeito colateral indevido. A ausência de idempotência gera inconsistências.
Alternativa D — ❌ Incorreta
Garantir que apenas um consumidor receba cada evento limita o modelo de pub/sub, em que múltiplos consumidores podem se inscrever no mesmo evento para diferentes finalidades. Além disso, a restrição reduz escalabilidade e resiliência, pois cria um gargalo único. Arquiteturas event-driven frequentemente permitem múltiplos consumidores com garantias de consistência via idempotência.
Alternativa E — ❌ Incorreta
"Fire-and-forget" sem confirmação ou retry é arriscado: se o evento for perdido, não há recuperação. Arquiteturas robustas utilizam mecanismos de confirmação (acknowledgment) e retentativas para garantir a entrega, mesmo em falhas temporárias. A resiliência exige confiabilidade, não mero descarte.
Gabarito: letra B.