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”
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.