Durante muito tempo, eu acreditei que eficiência era fazer tudo na hora.
Recebe. Processa. Entrega.
Simples assim.
Mas, quando conectamos o ATweb ao WhatsApp, anos atrás — antes mesmo de existir a API oficial —, essa lógica começou a mostrar suas limitações.
As mensagens chegavam diretamente na nossa aplicação. Se ela estivesse fora do ar naquele momento, podíamos perder mensagens. Se o volume aumentasse demais, o processamento pesava e o sistema inteiro sentia.
E, claro, o cliente percebia.
A virada de chave aconteceu quando participei de um evento da AWS e conheci melhor o conceito de filas de mensageria e processamento assíncrono.
Foi quando entendi algo que hoje parece óbvio:
Nem tudo precisa ser processado na hora.
Passamos então a direcionar as mensagens para filas no Amazon SQS. Em vez de a aplicação precisar receber e processar tudo imediatamente, a mensagem ficava segura na fila e um serviço consumidor cuidava do processamento.
Se houvesse um pico, tudo bem. Se o processamento demorasse um pouco mais, tudo bem. Se algum componente tivesse uma indisponibilidade temporária, a mensagem continuava lá, esperando.
O impacto foi enorme.
A aplicação deixou de carregar todo aquele processamento, ficou mais resiliente e vimos uma queda brusca nas reclamações de lentidão.
Depois disso, começamos a levar o mesmo conceito para outras partes do ATweb.
Um encerramento de 100 atendimentos, por exemplo, não precisava mais deixar o usuário olhando para uma tela carregando enquanto o sistema fazia 100 operações. Colocamos o trabalho em uma fila, processamos em segundo plano e deixamos o front-end apenas acompanhar o resultado.
Parece uma mudança técnica.
Mas, para mim, o principal aprendizado não foi sobre SQS, Kafka, RabbitMQ ou qualquer tecnologia específica.
Foi sobre questionar a arquitetura.
Às vezes passamos anos tentando deixar um processo mais rápido, quando a pergunta deveria ser outra:
Esse processo precisa acontecer aqui? Precisa acontecer agora? Precisa mesmo ser síncrono?
Implementar tudo isso em um sistema que já atendia diversos clientes também não foi simples. Foi o famoso “trocar o pneu com o carro andando”. Tivemos que evoluir a arquitetura sem simplesmente parar tudo e começar novamente.
Mas valeu a pena.
Tecnologia também é isso: entender que uma solução que funcionou muito bem durante anos pode não ser a melhor solução para o próximo estágio.
Nada é tão bom que não possa ser melhorado.
Às vezes, a próxima grande melhoria do seu sistema não está em processar mais rápido, mas sim em simplesmente em entender o que você precisa processar agora e o que pode ficar pra depois.
Até a próxima 😉