[Conceito] - Filas/Tópicos: Processar Mensagens Fora de Ordem
Published: 2022-09-27 19:53:24

> Conteúdo original em https://twitter.com/zanfranceschi/status/1574848219833462784

---

Ei dev,

Quando estiver trabalhando com filas e bater aquela dor de barriga porque as mensagens não estão chegando em ordem e isso for um problemão, eu tenho uma alternativa relativamente simples pra você!

Cola mais pros detalhes!

cc @sseraphini

↓

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fmmp9t1gksz7nelgrvhn.png)

---

Primeiro, vamos pensar num cenário onde a ordem da chegada das mensagens importa.

Extrapolei o diagrama de sequência, mostrando dois fluxos em um – publicação/consumo das mensagens –, para simplificar a linha do tempo dos acontecimentos.

Aqui, apenas o caminho feliz é mostrado.

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5hfod5zwsnxm4h3u12r3.png)

---

Só que problemas acontecem e pode rolar da mensagem do pedido chegar antes da mensagem do seu usuário correspondente! E agora?! 😱

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mbsoij8udq56vz4mpfbi.png)

---

Uma série de coisas pode ter ocorrido:

- Mensagens de usuários cadastrados podem ser lentas pra processar.

- A publicação do usuário cadastrado pode ter tido um problema.

- Num cenário de consumo paralelo das mensagens, a ordem calhou de estar incorreta.

- Etc.

C'est la vie.

---

Agora que você entendeu o problema do consumo fora de ordem das mensagens, antes de ler o próximo tweet, pára e pensa como resolveria isso.

Sua ideia ficou muito mirabolante ou ficou simples? Já passou por esse problema? 👀

---

Como disse anteriormente, a alternativa aqui sugerida é simples. E o primeiro passo é devolver a mensagem para um canal (fila/tópico) de retry.

Cada middleware possui especificidades, mas a ideia central é a mesma para todos.

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k7cpmhpxgg189rlipkfa.png)

---

Essa mensagem deve ficar nesse canal (tópico ou fila) por um tempo configurável – segundos, minutos, horas, etc.

Após esse TTL (time to live – expiração) ocorrer, o consumidor, de alguma forma, deve processar novamente essa mensagem.

Esse passo pode se repetir algumas vezes.

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jz4zaw9c71yj1ruax3eh.png)

---

Essa retentativa pode ser via canal original ou canal de retry – depende do middleware e de detalhes de implementação.

Não é uma solução computacionalmente eficiente, mas é de fácil implementação pois reusa a infraestrutura existente de filas e mantém os consumidores stateless.

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k3fe5q2s5kcpplesbwad.png)

---

Novamente, a ideia central é devolver para o middleware de mensagens/streaming as mensagens que não foram possíveis de serem processadas para que estas voltem posteriormente ao consumidor que a devolveu. Eventualmente, a ordem das mensagens ficará correta e tudo se encaixará.

---

Alguns pontos importantes:

- Cuidado com a quantidade de retries – sempre coloque um limite.

- Calibre com carinho o intervalo das retentativas – cuidado para não transformar os retries num auto-ataque!

- Não use para casos em que pouco lag for essencial.

---

E o mais importante, procure entender como paralelismo, multithreading, altos volumes, etc. impactam em soluções de processamentos assíncronos usando filas/tópicos. Experimente, estude, faça POCs.

E não canso de recomendar Enterprise Integration Patterns para esse assunto.

![Image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xjqjrfq53uuix1pm85xj.png)

---

Obrigado demais pra você que chegou até aqui! ♥️

Se curtiu o conteúdo, dá um RT no primeiro tweet, like, comenta, compartilha, mostra pros seus filhos, vizinhos, e no grupo do zap. 🤭