# \[ARQUITETURA ORIENTADA A EVENTOS\] Dúvida sobre o pattern fire-and-forget **URL:** \ **Category:** Livros\ **Created:** [Fevereiro 13, 2025, 10:52pm UTC](https://forum.casadocodigo.com.br/t/arquitetura-orientada-a-eventos-duvida-sobre-o-pattern-fire-and-forget/2332 "2025-02-13T22:52:43Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Arthur98](https://avatars.discourse-cdn.com/v4/letter/a/ecb155/32.png) [@Arthur98](https://forum.casadocodigo.com.br/u/Arthur98)\ **Post date:** [Fevereiro 13, 2025, 10:52pm UTC](https://forum.casadocodigo.com.br/t/arquitetura-orientada-a-eventos-duvida-sobre-o-pattern-fire-and-forget/2332/1 "2025-02-13T22:52:43Z")
Na página 61 é falado sobre o pattern fire-and-forget, já utilizei ele algumas vezes, em uma delas, tínhamos um endpoint que precisava gerar um relatório, esse endpoint era muito lento, respondia em 5 segundos em média, porque tinha muitos dados na aplicação, e era uma query complexa, demandava muito processamento… Então, começamos a gerar o relatório de forma assíncrona, utilizando mensageria para processar em plano de fundo, e enviando o link por email após processamento, dessa forma, quando chega uma request para o endpoint, é enviado a solicitação para a fila (fire), e retorna de imediato um 200 OK (forget), me corrija se eu estiver errado, mas acredito que essa implementação se encaixa no fire-and-forget… O que me deixou com a pulga atrás da orelha, foi um trecho do livro, ainda na página 61: “[…] o produtor não precisa aguardar até que o evento seja entregue para o consumidor, ele pode seguir seu fluxo de processamento assim que o broker aceitar o evento” Mas se tratando de request-reply, como vou seguir com o fluxo de processamento? Posso prosseguir com o fluxo mas, em algum momento vou precisar dar um wait na thread pra esperar a resposta do evento, certo? Supondo que o fluxo dependa da resposta do evento, porque o request-reply diz que “o produtor precisa de uma resposta em um momento no futuro” Não sei se meu entendimento está correto… ---
**Author:** ![roberto.picanco](https://avatars.discourse-cdn.com/v4/letter/r/a183cd/32.png) [@roberto.picanco](https://forum.casadocodigo.com.br/u/roberto.picanco)\ **Post date:** [Fevereiro 21, 2025, 11:10am UTC](https://forum.casadocodigo.com.br/t/arquitetura-orientada-a-eventos-duvida-sobre-o-pattern-fire-and-forget/2332/2 "2025-02-21T11:10:40Z")
Um exemplo bom de fire-and-forget que gosto de dar é no momento da publicação em um tópico Kafka. O produtor no Kafka pode ter as seguintes configurações de acks: 1 - acks=0 → Significa que o produtor não aguarda uma confirmação do broker. 2 - acks=1 → Significa que o produtor aguarda apenas a configuração do leader. 3 - acks=all → Significa que o produtor vai aguardar o leader que por sua vez vai aguardar a confirmação de todos os followers. Se estamos utilizamos o Kafka e nosso produtor está configurado com acks=0, temos um fire-and-forget. O benefício que ganhamos velocidade e o ponto negativo é que podemos perder a mensagem, uma vez que não tivemos confirmação de recebimento. Daí vai de acordo com o caso de uso. Sobre o request-reply, você pode seguir ou finalizar o fluxo e processar a resposta no futuro. Se você precisa aguardar uma resposta, talvez o melhor caminho seria usar uma comunicação síncrona clássica ou reativas. Abraço ---
**Author:** ![Arthur98](https://avatars.discourse-cdn.com/v4/letter/a/ecb155/32.png) [@Arthur98](https://forum.casadocodigo.com.br/u/Arthur98)\ **Post date:** [Fevereiro 21, 2025, 1:43pm UTC](https://forum.casadocodigo.com.br/t/arquitetura-orientada-a-eventos-duvida-sobre-o-pattern-fire-and-forget/2332/3 "2025-02-21T13:43:53Z")
Muito obrigado pela atenção e as respostas Roberto, me ajudaram muito! Abri mais uma pergunta no fórum, responda quando puder, dessa vez sobre Event Sourcing > [@\[ARQUITETURA ORIENTADA A EVENTOS\] Onde está o Event Sourcing na Figura 3.20](https://forum.casadocodigo.com.br/t/arquitetura-orientada-a-eventos-onde-esta-o-event-sourcing-na-figura-3-20/2333): > > Eu não conhecia o Event Sourcing, apenas ouvia falar, lendo o livro, entendi que Event Sourcing é quando consumimos uma fila, e quando um evento for publicado, invés de apenas rodar um update no banco, gravamos um registro novo para manter histórico Fiquei um pouco confuso na parte sobre CQRS com Event Sourcing, eu consegui enxergar perfeitamente o uso do Event Sourcing na Figura 3.19, pois o próprio broker de eventos está fazendo o papel do banco de dados de escrita, utilizando um broker com p…