Existem situações que realmente nos exigem utilizar comunicação assíncrona devido à sua complexidade.
Numa compra, por exemplo, há uma série de procedimentos, como: gerar nota fiscal, avisar o centro distribuidor, a contagem de estoque, rodar processos de machine learning, atualizar o índice de busca, mudar o cache, etc. Basear todos esses processos de forma síncrona é muito trabalhoso, além da preocupação que nós temos de observar diversos eventos. E, mesmo assim, cada sistema prioriza a sua comunicação com base nas requisições, sejam quais forem.
Então isso faz muita diferença pela diversidade de formas que um único produtor pode escolher para transmitir uma mensagem entre várias pessoas.
Utilizando Tópicos
Uma comunicação síncrona pode exigir mudança de código, o trabalho de adicionar mais uma API e fazer um deploy, deixando todo o nosso evento bastante restrito a isso.
Na grande quantidade de filas do Mercado Livre, por exemplo, existem diversas equipes para cuidar dos processos de pagamento dessa plataforma, que consomem essas informações e ainda cuidam de várias coisas.
E como as equipes envolvem diversas pessoas, é muito difícil saber as suas funções. E se elas também quiserem consumir um evento de pagamento, é muito mais fácil fazer isso através de um tópico, que é um modelo muito mais escalável em comparação ao síncrono.
Como as comunicações funcionam no mercado?
Negócios de grande escala geralmente não aceitam o modelo síncrono.
Quando você faz uma compra, por exemplo, um dos primeiros passos é reservar o dinheiro do seu cartão de crédito, que envia uma mensagem para que a processadora determine a quantia que você vai pagar de acordo com o preço do produto. Logo depois é feita uma análise de fraude e, dependendo do negócio, esse processo pode ser feito online ou levar até dois dias numa mesa de análise manual.
Mas nós não podemos deixar a compra pendurada por dois dias no site, aguardando com a sua conexão aberta, então normalmente esses sistemas fazem a comunicação por filas da seguinte forma: Um evento é colocado para debitar o dinheiro do usuário; seguindo para a análise de fraude, que vai processá-lo de forma automática ou manual; e ao terminar ele adiciona um próximo evento que é consumido por outros X assinantes.
Nessa relação é confirmado se houve fraude ou não, mas se a compra for legítima, aquele que tomar a próxima ação consegue, através do evento, capturar o dinheiro e fazer o débito efeito no cartão.
Se você já reparou, quando fazemos uma compra online normalmente nós recebemos uma mensagem declarando que o pedido foi feito, e depois de um tempo outra mensagem para confirmar que o dinheiro do cartão foi debitado. Então esse não é um fluxo síncrono; mas sim um fluxo assíncrono rodando por trás disso.
Transações & Processamento: A comunicação nos e-commerces
Muitos e-commerces sequer avisam se a compra foi autorizada ou não; eles apenas declaram que o pedido foi feito, pois se a processadora do cartão estiver lenta ou qualquer coisa do tipo, o usuário não precisa ficar horas esperando. E se a compra não deu certo basta retornar com uma mensagem de erro, com o risco de perder a venda. Mas uma vez que você tem essa informação, você já sabe que pode haver um delay naquele momento e retornar depois.
Vemos que trabalhar de forma síncrona não é ruim; existem situações que realmente pedem sincronismo, mas é importante se lembrar que essa decisão deve ser feita pensando no usuário final. Se você vai reservar uma passagem aérea, por exemplo, naquele momento existem muitas outras pessoas com o interesse de reservar aquele mesmo lugar.
Existem muitos sites nos quais você deve esperar, por conta de diversos fatores que estão acontecendo por trás daquele negócio. E quando eles não respondem de imediato pode ser pela precaução de que se alguma coisa der errado, o negócio pode se reorganizar.
Então isso tem muito mais a ver com o negócio e depende de como a empresa confirma se a sua compra foi aprovada ou se ela apenas recebeu o seu pedido Mas se alguma coisa der errado a empresa pode te enviar um email ou avisar usando outra forma de comunicação.
Como garantir o bem-estar das suas comunicações?
Na maioria das vezes nós precisamos adaptar a nossa aplicação para funcionar com esse tipo de comunicação, já que num esquema síncrono o usuário recebe a resposta de imediato; mas de forma assíncrona é preciso encontrar um meio de seguir o processo de alguma forma, portanto é preciso ter controle.
Como isso resolve alguns problemas e adiciona outros, nós devemos saber quando usar os nossos recursos em cada caso, além de entender bem o sistema para garantir que ele vá suportar um esquema de comunicação assíncrona.
De ambas as formas nós devemos nos esforçar para que tudo funcione da melhor maneira porque ter esse controle é muito importante. E não basta adicionar mais filas; é preciso ter observabilidade em relação a isso, com uma visão geral de tudo o que está acontecendo.
Escalas de Comunicação
Um exemplo muito claro disso é quando você tem uma fila que mantém a comunicação entre dois microsserviços, mas por algum motivo o broker te entregou uma mensagem que não foi reconhecida no processamento. E ele tenta enviar essa mensagem novamente. Se isso representa o débito de uma conta corrente, por exemplo, pode haver um erro no qual ele acaba debitando o dinheiro duas vezes. Um típico caso de compra duplicada.
Para controlar esse tipo de coisa a sua aplicação deve estar bem preparada para trabalhar num modelo assim, pensando em toda aplicação em si.
No conceito de idempotência a sua aplicação deve receber uma coisa mais de uma vez, mas sem apresentar efeitos colaterais como a duplicação de eventos. E preparar toda a sua aplicação para isso não é uma coisa simples.
Estendendo um pouco esse raciocínio, na ideia de ter dois microsserviços – um serviço que faz o débito na conta corrente de um usuário, enquanto o outro serviço credita o valor na conta corrente do outro usuário. No caso, essa é uma situação típica onde uma pessoa quer pagar uma dívida com outra.
Se o dinheiro debitado na conta do usuário que enviou a mensagem relativa ao crédito na conta do outro, que recebeu, essa transferência funcionou como esperado. Mas e se o outro usuário não receber o valor, que já foi debitado, como o primeiro microsserviço vai cuidar da devolução desse dinheiro?
Nessa escala de dois microsserviços a solução pode parecer simples, mas quando você tem cinquenta microsserviços para fazer todo esse processo de transferência envolve uma complexidade muito maior, que deve ser bem pensada e projetada para esse tipo de escala.
Seja em grande escala; processos de negócio demorados, que não podem deixar o usuário pendurado; num site pequeno, com menos processos e um esquema síncrono, que é mais simples. No geral é preciso pensar muito bem nesse tipo de decisão.
Controle de Escalas
Nesse cenário é comum se descuidar, já que as coisas são completamente separadas e você utiliza programas para resolver isso, mas muitos desses casos são complexos, principalmente quando envolvem dinheiro, crédito, falhas de débito e estorno.
E como já foi mostrado, trabalhar isso com dois microsserviços é fácil; mas quando você tem uma grande escala de microsserviços, num grande comércio, as coisas ficam muito mais difíceis de se gerenciar.
