DoorDash Construyó un Sistema CDC Personalizado Cuando Debezium Alcanzó sus Límites de Escala

Los ingenieros de DoorDash presentaron WAIL—Write-Ahead Intent Log—en QCon San Francisco 2025, una arquitectura CDC personalizada construida cuando Debezium alcanzó límites operacionales bajo carga máxima de tráfico de pedidos. El patrón ahora sustenta la captura de cambios en cientos de servicios de DoorDash.

El problema raíz es la fragilidad del dual-write. Cuando un pedido llega a la base de datos de pedidos, una segunda escritura debe disparar simultáneamente un evento al sistema de streaming. Cuando la escritura de la base de datos tiene éxito pero la escritura del evento falla—o viceversa—los sistemas downstream divergen. La consecuencia es concreta: el restaurante nunca recibe la notificación del pedido, el conductor nunca es despachado, el cliente ve un spinner hasta que la falla escala a un reembolso.

CDC estándar se suponía que resolvería esto. Debezium lee el transaction log de la base de datos y emite eventos de cambio a Kafka, eliminando la condición de carrera del dual-write. En teoría. En entornos heterogéneos—múltiples motores de base de datos, cada uno con su propio dialecto WAL—los conectores de Debezium se convierten en máquinas de estado por-motor que necesitan ajuste individual. Bajo la carga máxima de DoorDash, Debezium alcanzó sus límites. El modo de falla es consistente con el comportamiento conocido de Debezium a escala: retraso LSN, bloqueos de conector en cambios de esquema, y backpressure propagándose aguas arriba cuando un sink se cae.

WAIL reestructura el handoff en dos componentes: un proxy de productor simple que solo registra la intención de un cambio, y un consumidor inteligente que resuelve el estado. El productor hace un trabajo mínimo—registra la intención, retorna. No incorpora un payload completo de before/after. El consumidor obtiene el estado actual cuando procesa la entrada del registro de intención. Esta separación mantiene la ruta del productor rápida y aislada de fallos; el bloqueo de un consumidor no bloquea a los escritores ni corrompe el registro.

El patrón de consumidor inteligente cambia la responsabilidad de la consistencia de estado de la ruta de escritura a la ruta de lectura. Un conector de Debezium que mantiene ranuras de replicación, rastrea LSN y administra offsets de Kafka es un componente con estado fuertemente acoplado tanto a la base de datos como al broker. Cuando algo falla—el sink se cae, la ranura de replicación se queda atrás, el broker rebalancea las particiones—el radio de falla cubre la ruta de escritura. El productor simple de WAIL no tiene ranura de replicación, sin estado de offset, sin acoplamiento de broker. Se añade a un registro. El consumidor reconcilia.

A la escala de DoorDash, los beneficios prácticos son visibilidad y recuperabilidad. Un registro de intención orientado al dominio es auditable: puede reproducir desde cualquier punto, enrutar a múltiples consumidores e instrumentar la latencia a nivel de intención independientemente de la latencia de resolución de estado. La presentación encuadra el objetivo como pasar de arquitectura frágil a una que es "durable, visible y recuperable." Las mejoras específicas de SLA no se publican.

La complejidad del lado del consumidor sí aumenta. Cuando el consumidor inteligente obtiene el estado actual, debe manejar casos donde la fila de la base de datos ha sido actualizada nuevamente—la intención y el estado actual ya no están sincronizados. Esto requiere una lógica cuidadosa de idempotencia y seguimiento de versiones. Los equipos que operan Debezium a escala ya lidian con esto a través de la alineación snapshot-plus-stream; WAIL mueve el problema en lugar de borrarlo.

Para equipos cuya pila CDC abarca bases de datos heterogéneas y que están quemando ciclos de connector-ops bajo carga máxima, separar el intent logging de la resolución de estado es un refactor estructuralmente sólido. El consumidor inteligente es donde aterrizan la complejidad, no donde desaparece.