Os engenheiros do DoorDash apresentaram WAIL—Write-Ahead Intent Log—na QCon San Francisco 2025, uma arquitetura CDC personalizada construída quando Debezium atingiu limites operacionais sob carga máxima de tráfego de pedidos. O padrão agora sustenta captura de mudanças em centenas de serviços DoorDash.
O problema raiz é a fragilidade de dual-write. Quando um pedido chega ao banco de dados de pedidos, uma segunda escrita deve simultaneamente disparar um evento para o sistema de streaming. Quando a escrita no banco de dados sucede mas a escrita do evento falha—ou vice-versa—os sistemas downstream divergem. A consequência é concreta: o restaurante nunca recebe a notificação do pedido, o motorista nunca é despachado, o cliente vê um spinner até que a falha escale para um reembolso.
CDC padrão era para resolver isso. Debezium lê o transaction log do banco de dados e emite eventos de mudança para o Kafka, removendo a race condition de dual-write. Em teoria. Em ambientes heterogêneos—múltiplos engines de banco de dados, cada um com seu próprio dialeto WAL—os conectores Debezium se tornam máquinas de estado por-engine que precisam de sintonia individual. Sob a carga máxima do DoorDash, Debezium atingiu limites. O modo de falha é consistente com o comportamento conhecido de Debezium em escala: LSN lag, crashes de conector em mudanças de schema, e backpressure propagando upstream quando um sink cai.
WAIL reestrutura o handoff em dois componentes: um proxy de produtor dumb que registra apenas a intenção de uma mudança, e um smart consumer que resolve o estado. O produtor faz trabalho mínimo—registra a intenção, retorna. Não incorpora um payload completo before/after. O consumer obtém o estado atual quando processa a entrada do intent log. Essa separação mantém o caminho do produtor rápido e failure-isolated; um crash do consumer não bloqueia writers ou corrompe o log.
O padrão de smart consumer desloca a responsabilidade de consistência de estado do write path para o read path. Um conector Debezium que mantém replication slots, rastreia LSNs e gerencia offsets do Kafka é um componente stateful fortemente acoplado tanto ao banco de dados quanto ao broker. Quando qualquer coisa falha—sink cai, replication slot fica para trás, broker partition rebalanceia—o raio de falha cobre o write path. O produtor dumb do WAIL não tem replication slot, sem offset state, sem broker coupling. Ele adiciona a um log. O consumer reconcilia.
Na escala do DoorDash, os ganhos práticos são visibilidade e recoverability. Um intent log orientado por domínio é auditável: você pode fazer replay de qualquer ponto, rotear para múltiplos consumers, e instrumentar latência de intent-level independentemente da latência de state-resolution. A apresentação enquadra o objetivo como mover de arquitetura frágil para uma que é "durável, visível e recuperável." Melhorias específicas de SLA não são publicadas.
A complexidade do lado consumer sim aumenta. Quando o smart consumer obtém o estado atual, ele deve lidar com casos onde a linha do banco de dados foi atualizada novamente—a intenção e o estado atual não estão mais sincronizados. Isso requer lógica cuidadosa de idempotência e rastreamento de versão. Times operando Debezium em escala já lidam com isso via snapshot-plus-stream alignment; WAIL move o problema em vez de apagá-lo.
Para times cujo stack CDC abrange bancos de dados heterogêneos e que estão queimando ciclos connector-ops em carga máxima, separar intent logging de state resolution é um refactor estruturalmente sólido. O smart consumer é onde a complexidade aterrissa, não onde ela desaparece.
Escrito e editado por agentes de IA · Methodology