O que realmente acontece quando o sandoval morre em vis a vis
A maioria das pessoas que trabalha com integração de sistemas se depara com o problema sem entender o que está acontecendo. O sintoma mais comum é o serviço parecer travado, com requisições entrando e saindo pelo mesmo ponto, gerando um loop que consome recursos até o sistema cair. Isso não é um erro de rede, nem falha de configuração básica. É um padrão que aparece com frequência quando dois serviços tentam se comunicar diretamente sem um mediador adequado. Vis a vis significa olho no olho, face a face. No contexto técnico, refere-se à comunicação direta entre dois processos sem intermediários. Quando o Sandoval — que é um wrapper de orquestração que muitos usam para gerenciar filas e retries — entra nesse cenário, o problema emerge porque ele não foi projetado para esse tipo de interação. O loop se forma quando a resposta de um deles é interpretada como gatilho para nova requisição do outro.
sandoval morre em vis a vis
A expressão surgiu nos fóruns técnicos há uns dois anos quando um desenvolvedor chamou assim um bug recorrente em produção. O cenário era simples de descrever e difícil de rastrear: dois microsserviços falando diretamente, um usando Sandoval para gerenciar suas chamadas, e nenhum deles sabendo quando parar. O nome viralizou porque descrevia exatamente o que acontecia — o Sandoval "morria" nessa interação direta, consumindo memória e CPU até ser derrubado. No meu caso, o problema apareceu num sistema de notificação que precisava validar dados antes de enviar. Tinhamos um serviço A que chamava o serviço B, o B processava e respondia, e o Sandoval no serviço A interpretava a resposta como sinal para reprocessar. O resultado foi um processo que levou 47 minutos para enviar 3 notificações, consumindo 2,3 GB de RAM e gerando logs de cerca de 800 MB.
A solução que funcionou envolveu três mudanças concretas. Primeiro, substituímos a chamada síncrona direta por uma fila gerenciada. O serviço A coloca a mensagem na fila, o serviço B lê e processa, e não há retorno direto. Segundo, configuramos um dead letter queue com timeout de 30 segundos, então mensagens que não forem processadas vão para um canto seguro em vez de ficarem girando. Terceiro, adicionamos um identificador de correlação em cada mensagem, o que permite rastrear cada interação sem depender de timestamps que podem colidir em ambientes com alta carga. Isso reduziu o tempo médio de processamento de 47 minutos para aproximadamente 4 segundos por lote de 100 mensagens. A consumo de memória caiu de 2,3 GB para cerca de 180 MB. Os logs passaram de 800 MB para algo em torno de 12 MB no mesmo período.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O erro mais comum que vejo gente cometendo é tentar consertar isso só aumentando timeouts ou ajustando retries. Não funciona. O problema não é timing, é arquitetura. Adicionar mais retry apenas alimenta o loop. Aumentar o timeout só dá tempo para o processamento degradar mais antes de explodir. Você precisa quebrar o ciclo na raiz. Outro detalhe que quase ninguém considera é o impacto no versionamento. Quando você introduz uma fila entre os serviços, o contrato muda. O serviço A agora produz eventos, não faz chamada direta. O serviço B consome eventos. Isso parece óbvio, mas em times que trabalham com deploy contínuo, essa transição costuma gerar incompatibilidades se não for planejada. Testamos isso num cenário real onde o serviço B tinha uma versão legada que não processava o campo de correlação. Levou duas semanas de ajustes porque o campo novo era ignorado silenciosamente, não gerava erro, só causava perda de rastreamento.
Se o seu sistema ainda está em fase inicial e você está avaliando se vale a pena fazer essa migração, a resposta depende do volume. Para sistemas que processam menos de 50 mensagens por minuto, o overhead da fila pode não justificar a complexidade adicional. Nesses casos, um simple backoff exponencial com circuit breaker pode resolver sem necessidade de arquétipo completo de mensageria. Para volumes acima de 200 mensagens por minuto, a fila é praticamente obrigatória. Abaixo disso, você pode sobreviver com mecanismos mais simples, mas saiba que vai chegar num ponto onde a solução improvisada vai travar exatamente no pior momento possível, geralmente em horário comercial quando todo mundo está online.
A documentação oficial do Sandoval não menciona esse comportamento explicitamente. Eles focam em uso com filas nativas e não cobrem o cenário de vis a vis porque tecnicamente é um anti-pattern. Mas no mundo real, muitas equipes acabam chegando nessa situação por Pressão de prazo, por falta de conhecimento da arquitetura ou por herdar código de quem estava nessa armadilha antes. O importante é reconhecer o padrão cedo e cortar o ciclo antes que vire problema de produção.
