O dia em que a Salesforce descobriu que sua observabilidade tinha um ponto único de falha global
Como o Argus, plataforma interna que ingere 4 bilhões de métricas por minuto, saiu de uma arquitetura mono-região para um modelo geo-local sem estourar o orçamento de infraestrutura
A Salesforce reprojetou o Argus, sua plataforma interna de observabilidade, para eliminar a dependência de uma única região AWS. O case traz lições diretas sobre blast radius, federação de queries e trade-off entre resiliência e custo que valem para qualquer arquitetura multi-região.
Tem uma pergunta que todo arquiteto deveria fazer antes de assinar um desenho de solução: "o que acontece se essa região cair?". A resposta, na maioria dos projetos que eu vejo por aí, é algum tipo de silêncio constrangido. Foi exatamente esse silêncio que o time do Argus, a plataforma interna de observabilidade da Salesforce, resolveu encarar de frente.
O Argus não é um produto que você vê no Setup. É a espinha dorsal invisível que monitora dashboards, alertas e métricas de milhares de times de engenharia dentro da própria Salesforce, processando algo próximo de 4 bilhões de métricas por minuto. Ou seja: é a ferramenta que os engenheiros usam para descobrir o que está quebrado quando algo quebra. E durante anos, essa ferramenta tinha uma dependência crítica de uma única região AWS.
Isso não é um detalhe técnico menor. Se aquela região específica tivesse um incidente, a visibilidade de todo o Argus, globalmente, ia junto. Não era "a região X caiu e afetou o que roda na região X". Era "a região X caiu e agora ninguém em lugar nenhum consegue ver métrica de nada". Esse é o conceito de blast radius, o raio de estrago de uma falha, e nesse desenho ele era, na prática, o tamanho da empresa inteira.
Por que não bastava replicar tudo
A saída óbvia, replicar os dados em múltiplas regiões, foi descartada rapidamente. Na escala do Argus, manter cópias completas em várias regiões custaria uma fortuna em recursos AWS, além de aumentar latência e custo de transferência de dados, já que telemetria de todas as outras regiões precisaria ser enviada para um ponto central de processamento.
A solução que o time desenhou, batizada de modelo geo-local, foi mais sofisticada: em vez de duplicar tudo, os dados passaram a ser processados e armazenados mais perto da origem da métrica, reduzindo dependências cross-region e melhorando o isolamento de falhas sem replicar o volume inteiro. Foi um esforço de seis meses, juntando três times (Argus, Argus India e o time de HBase), repensando ingestão, armazenamento e responsabilidade regional. Hoje isso está em produção em 4 das 5 regiões, faltando só a última etapa do rollout.
O problema que a distribuição cria: queries parciais
Aqui está o ponto que eu acho mais interessante do case, e que qualquer arquiteto de integração vai reconhecer: distribuir dados resolve um problema e cria outro. Antes, uma query batia numa região só, e ou funcionava ou falhava. Com dados espalhados, uma query pode receber resposta de algumas regiões enquanto outra está indisponível. Isso exige lidar com resultado parcial de forma explícita, não como bug.
A resposta foi uma camada de federação de queries. Ela mantém um metadado global de onde cada escopo de métrica realmente vive (com Elasticsearch por trás disso) e roteia a consulta só para as regiões relevantes, em vez de fazer fan-out para todo mundo. Isso evita tráfego cross-region desnecessário e mantém a latência controlada. E quando uma região não responde, o sistema não falha silenciosamente: ele retorna HTTP 206 (Partial Content) e a interface avisa o usuário que parte do dado está indisponível, em vez de fingir que tudo está ok.
O paralelo com projetos de CRM é direto. Toda vez que você desenha uma integração multi-org, um Data Cloud consumindo múltiplas fontes, ou até um Experience Cloud com sharing distribuído entre unidades de negócio, a pergunta é a mesma: o que o usuário vê quando uma parte do sistema falha? Falha silenciosa é sempre a opção mais perigosa, porque ninguém percebe até o dado errado já ter virado decisão de negócio.
Esse case não é sobre observabilidade em si, é sobre um princípio de arquitetura que se aplica a qualquer sistema distribuído dentro do ecossistema Salesforce: reduzir blast radius quase nunca significa replicar tudo, significa isolar dependências e ser honesto sobre estados parciais. Quem desenha integrações MuleSoft multi-região, arquiteturas de Data Cloud com múltiplas fontes ou soluções multi-org sente na pele esse mesmo trade-off entre resiliência e custo.
Para arquitetos de solução, o ponto de atenção é a diferença entre alta disponibilidade e isolamento de falha. Você pode ter um sistema "disponível" que ainda assim tem um único ponto capaz de derrubar tudo. O modelo geo-local ataca exatamente esse segundo problema, que costuma passar batido em desenhos apressados.
Vale destacar que este é um relato de engenharia interna da própria Salesforce sobre sua infraestrutura de observabilidade, não uma feature de plataforma que aparece no Setup do seu org. Não há aqui nenhuma mudança direta em Flow, CPQ, Revenue Cloud ou Data Cloud para o cliente final. O valor está no raciocínio arquitetural exposto, que serve de referência para quem desenha sistemas distribuídos, integrações multi-região ou avalia resiliência de plataformas próprias construídas sobre a Salesforce (via Heroku, MuleSoft ou infraestrutura própria).
Use esse case como checklist mental na próxima revisão de arquitetura: pergunte explicitamente "qual é o blast radius dessa dependência regional/de sistema único?" antes de aprovar o desenho. Se a resposta for "tudo cai", isso é um risco de arquitetura, não um detalhe operacional para tratar depois.
Se você trabalha com integrações distribuídas (MuleSoft, Data Cloud com múltiplas fontes, multi-org), pense em resultado parcial como cidadão de primeira classe do desenho, não como exceção a ser tratada depois. Definir como a interface comunica dado incompleto (e não simplesmente omitir) evita decisões de negócio tomadas sobre informação truncada sem ninguém saber.
Cuidado ao tentar replicar esse padrão sem ter o mesmo nível de maturidade operacional: federação de queries e isolamento geo-local exigem metadado confiável sobre onde cada dado vive, e isso é caro de manter atualizado. Sem esse metadado preciso, você troca um problema (blast radius) por outro (queries que erram o roteamento e retornam dado incompleto sem necessidade).
Também não confunda esse tipo de resiliência de infraestrutura com resiliência de processo de negócio. Ter a plataforma no ar durante um incidente regional não resolve nada se o processo humano de resposta a incidente, escalonamento e comunicação com cliente não acompanhar a mesma maturidade.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.