Síncrono funciona… até parar tudo

Japa Tela Preta #5

Tem uma fase de todo sistema em que tudo parece simples demais pra dar errado.

Você desenha um fluxo direto. Uma API recebe a requisição, chama outro serviço, que chama mais um, que no final devolve a resposta. Tudo síncrono. Tudo encadeado. Tudo acontecendo ali, na mesma requisição. É rápido, é fácil de entender e, principalmente, funciona muito bem no começo.

Você testa, sobe, mede o tempo de resposta e fica satisfeito. Tudo fluindo, sem fricção. Parece até que encontrou o caminho ideal.

E de fato, encontrou… para aquele momento.

O problema começa quando o sistema sai do laboratório e entra no mundo real. Porque ali, diferente do ambiente controlado, as coisas não se comportam como você espera. Um serviço começa a demorar um pouco mais. Uma integração externa oscila. Uma API de terceiro resolve responder mais lento ou simplesmente não responder.

E é aí que o comportamento muda completamente.

Aquela requisição que antes era rápida começa a ficar presa esperando resposta. Enquanto isso, novas requisições continuam chegando. Elas também entram na fila, também começam a esperar. De repente, o que era um pequeno atraso vira acúmulo. O acúmulo vira lentidão generalizada. E quando você percebe, o sistema inteiro está engasgando.

Não porque tudo quebrou.

Mas porque uma parte não respondeu no tempo esperado.

Esse é o ponto que pega muita gente desprevenida. No modelo síncrono, tudo está acoplado no tempo. Cada parte depende da outra terminar naquele exato momento. Quando uma sofre, o efeito não fica isolado. Ele se propaga. E isso cria o que, na prática, vira um efeito dominó.

Uma chamada lenta vira várias. O tempo de resposta cresce em cascata. Recursos começam a ser disputados. Threads ficam presas. Conexões acumulam. E algo que parecia perfeitamente estável começa a colapsar sob pressão.

É nessa hora que você percebe que o problema não era o código em si. Era o modelo.

E é exatamente aqui que sistemas mais maduros começam a evoluir.

Você começa a tirar coisas do caminho crítico da requisição. Introduz processamento assíncrono. Coloca filas no meio. Cria workers para processar tarefas fora do fluxo principal. Implementa retry de forma controlada. Passa a aceitar que nem tudo precisa acontecer na mesma hora.

Não é sobre performance.

É sobre resiliência.

Porque quando você desacopla o sistema no tempo, você impede que uma falha local vire um problema global. Se uma parte estiver lenta ou indisponível, o resto continua funcionando. Talvez com atraso, talvez com degradação controlada, mas continua.

E isso muda completamente a forma como o sistema se comporta em produção.

No começo, o foco é fazer funcionar.

Depois, o foco passa a ser garantir que, quando algo inevitavelmente der errado, o impacto seja limitado.

Porque vai dar.

Sempre dá.

E a diferença entre um sistema que aguenta e um que cai não está em evitar falhas. Está em como ele reage quando elas acontecem.

É nesse momento que você deixa de pensar só em fluxo…

e começa a pensar em sobrevivência.