DREAM: quando a orquestração distribuída se torna a linha de defesa contra ataques DDoS gerados por IA
Como a Salesforce reconstruiu, em três meses, a plataforma que protege 4,5 milhões de domínios e 3 milhões de orgs, e o que isso ensina sobre separar orquestração de dados em arquiteturas distribuídas
A Salesforce trocou a plataforma inteira de defesa contra DDoS em pouco mais de três meses, usando Temporal como orquestrador distribuído e IA para acelerar 90% da migração de código. O case expõe uma lição de arquitetura que vale muito além de segurança: coordenação não é lugar de guardar dado.
Todo arquiteto que já operou sistema multi-tenant em escala grande conhece esse pesadelo: um ataque mira um único cliente, mas o efeito colateral estoura em cima de outros mil que não têm nada a ver com a história. É exatamente esse o problema que a engenharia da Salesforce resolveu com o DREAM (DDoS Response and Mitigation), uma plataforma nova de defesa contra ataques DDoS que precisou nascer, ser testada e ir para produção em pouco mais de três meses, porque a licença da plataforma anterior estava expirando.
O cenário é brutal em escala: mais de 4,5 milhões de domínios, 3 milhões de orgs de clientes, SLA de 99,99% de disponibilidade, rodando sobre uma nuvem compartilhada que processa algo perto de 20 trilhões de transações por ano. Nesse tipo de arquitetura, ataque em camada de aplicação contra um único tenant pode consumir infraestrutura compartilhada e virar incidente para todo mundo ao lado. Não é ficção de arquitetura, é o dia a dia de qualquer plataforma multi-tenant que cresceu rápido demais para o modelo de isolamento original.
A decisão que evitou reinventar a roda (e salvou o prazo)
O time tinha três caminhos: construir do zero as primitivas de sistema distribuído (state management, retry, locks, failover), integrar várias tecnologias na mão, ou adotar um orquestrador distribuído já maduro. Escolheram o Temporal, e essa decisão sozinha explica boa parte de como um rebuild dessa magnitude coube em três meses.
Isso é uma lição que vejo repetida (e ignorada) em projetos Salesforce constantemente: time técnico bom insiste em resolver problema de orquestração e concorrência na mão, dentro de Apex ou de um Flow gigante, quando a plataforma (ou uma ferramenta madura de mercado) já resolveu isso. A separação entre orquestração determinística e efeitos colaterais externos (inferência de IA, telemetria, deploy de política, notificação) é o mesmo princípio que separa um Flow bem desenhado de um Frankenstein de subflows acoplados demais.
IA não substituiu engenheiro, acelerou a reescrita
O detalhe mais interessante do case não é o resultado final, é o processo: cerca de 100 mil linhas de código legado migradas com assistência de IA, a uma velocidade dez vezes maior que o ritmo anterior. Mais de 90% da reescrita foi assistida por IA, não autônoma. Isso significa padrão de código definido antes, modelo treinado nos padrões de programação do Temporal, revisão humana obrigatória, e IA gerando testes unitários até passar de 95% de cobertura.
Esse é o ponto que costumo repetir para cliente que quer jogar Agentforce em cima de processo mal desenhado: IA acelera trabalho bem estruturado, não substitui estrutura. O MVP funcional saiu em três semanas porque o time definiu disciplina de engenharia antes de acelerar com IA, não depois.
As duas lições de produção que valem para qualquer arquitetura distribuída
Duas falhas de produção ensinaram o princípio central da plataforma. Primeiro: dataset de telemetria grande demais passando direto pela camada de orquestração estourou o limite de tamanho de mensagem do transporte, e os workflows não degradavam graciosamente, simplesmente falhavam. A correção foi tirar dado volumoso da orquestração e passar só uma referência leve.
Segundo, mais sutil: workflow de longa duração acumula histórico de tudo que já executou, e esse histórico precisa ser reprocessado para reconstruir estado quando o trabalho retoma em outro nó. Conforme esse histórico cresce, a recuperação fica mais lenta, de forma gradual o suficiente para passar despercebida em teste e só aparecer em produção como timeout esporádico e difícil de reproduzir. A correção foi limitar esse histórico, carregando adiante só o estado necessário para o próximo passo.
O princípio que sobra desses dois incidentes é direto: camada de orquestração é coordenadora, não é repositório de dado. Ela existe para sequenciar trabalho de forma confiável (o que já rodou, o que vem a seguir, como recuperar), não para guardar o dado que o trabalho manipula.
Para quem arquiteta soluções Salesforce, o case do DREAM não é sobre segurança de perímetro, é sobre um princípio de design que se aplica a Flow, a integração via MuleSoft, a qualquer automação de longa duração: separar o motor que coordena do dado que está sendo processado. Automação que mistura as duas coisas tende a degradar de forma silenciosa até estourar em produção, exatamente como aconteceu com os workflows do Temporal antes da correção.
Também é um dado concreto sobre uso de IA em engenharia de software real, não em demo: 90% de um rebuild assistido por IA, mas com padrão de código, revisão humana e cobertura de teste como pré-requisito, não como opcional.
Este é um conteúdo de bastidor de engenharia da própria Salesforce, focado em infraestrutura de segurança e arquitetura distribuída, sem relação direta com Flow, Agentforce Revenue Management ou Revenue Cloud. A leitura aqui é de arquitetura de sistemas aplicada, com paralelos que valem para quem desenha automação e integração na plataforma.
Se você lida com automação de longa duração (Flow orquestrando múltiplos sistemas, integração via MuleSoft, processos batch), pergunte sempre: minha camada de orquestração está carregando dado grande demais entre etapas, ou só uma referência? E ela guarda um histórico que cresce sem limite ao longo da execução?
Se você está avaliando adotar IA para acelerar migração ou reescrita de código legado (Apex antigo, triggers, integrações), o modelo aqui é replicável: defina padrão de código antes, exija revisão humana em 100% do código gerado, e use IA para elevar cobertura de teste, não para substituir teste.
Não confunda velocidade de entrega com ausência de disciplina. O rebuild em três meses só funcionou porque o time definiu padrões de código e revisão humana antes de acelerar com IA. Aplicar essa velocidade sem essa disciplina em projeto Salesforce é receita para dívida técnica grande.
O problema do histórico de workflow crescendo sem limite é sorrateiro: passa em teste e só aparece em produção como timeout esporádico. Se você desenha processo de longa duração na Salesforce (aprovação multi-etapa, integração assíncrona), pense em como limitar o que fica acumulado no estado.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.