DoorDash вынес на QCon San Francisco не очередной рассказ про микросервисы, а вполне прикладную боль: классическая архитектура CDC начала сбоить там, где для бизнеса нет права на паузу, в часы пикового потока заказов. Компания показала собственный вариант решения, Write-Ahead Intent Log, или WAIL, и для команд, которые строят event-driven платформы поверх разнородных баз данных, это важнее любой красивой схемы на конференционном слайде.
О докладе Vinay Chella и Akshat Goel как пишет InfoQ: инженеры DoorDash разобрали, почему традиционный change data capture в их случае стал узким местом, а Debezium под высокой нагрузкой перестал быть универсальным ответом. Речь идет не о теории, а о довольно нервном производственном сценарии: во время dinner rush один заказ должен почти мгновенно пройти через базу заказов, уведомить ресторан, запустить логистику, обновить ETA в приложении и синхронизировать еще десятки зависимых сервисов. Если один сигнал выпадает, пользователь видит «обработку», ресторан не получает заказ, а платформа получает возвраты, эскалации и испорченный пользовательский опыт.
В DoorDash прямо называют старый подход хрупким. Самый очевидный антипример здесь — dual write, когда приложение одновременно пишет состояние в базу и отправляет событие в стриминговую систему. На бумаге выглядит аккуратно, в продакшене быстро превращается в рассинхрон правды: запись в БД прошла, событие не ушло, или наоборот. Альтернатива в виде polling тоже не спасает: она добавляет нагрузку на базу, дает лаг и заставляет downstream-системы реагировать с опозданием. Для платформы доставки, где изменение статуса заказа или остатка товара должно разлететься почти мгновенно, такая задержка уже не техническая мелочь, а прямой удар по бизнес-процессу.
На этом фоне и появляется WAIL. Ключевая мысль доклада довольно приземленная и потому полезная: важнее не само состояние записи, а намерение системы, то есть что именно должно произойти дальше. В DoorDash решили отделить intent от state payload и перестроили архитектуру вокруг этой идеи. Их схема использует связку dumb producer proxy и smart consumer: продьюсер остается максимально простым и фиксирует намерение заранее, а уже потребитель решает, как добрать нужное состояние, восстановить контекст и отработать бизнес-логику. По сути, команда уводит критичную часть из классического CDC-потока изменений на уровне БД в более управляемый слой, где проще обеспечивать наблюдаемость, повторную обработку и восстановление после сбоев.
Почему это вообще пришлось делать самостоятельно, хотя рынок давно живет с Debezium и похожими инструментами? Ответ у DoorDash не звучит как «готовые решения плохие». Скорее наоборот: традиционный CDC отлично работает, пока нагрузка, типы хранилищ и требования к консистентности не выходят за рамки условно нормального мира. У DoorDash мир давно не нормальный. В одном контуре живут разнородные базы, кеши, поисковые индексы, внутренние платформенные абстракции и множество сервисов, которым нужны изменения почти в реальном времени. На таком масштабе проблемы начинаются не в happy path, а в краевых режимах: коннекторы ломаются, sink'и отстают, разные хранилища говорят на разных «диалектах», а peak traffic не спрашивает, готова ли команда к очередной деградации.
Здесь доклад DoorDash попадает в более широкий тренд. За последние годы CDC из инструмента для ETL и аналитики окончательно переехал в слой операционной инфраструктуры. Его используют не только для витрин данных, но и для живых продуктовых сценариев: синхронизации заказов, обновления каталогов, реакций антифрода, пересчета ETA, работы кешей и поисковых систем. Отсюда и новая планка требований: мало просто снять изменения из WAL или binlog, нужно гарантировать, что downstream-сервисы поймут событие одинаково, смогут воспроизвести его после сбоя и не утонут в лишнем payload. В этом смысле архитектура CDC начинает напоминать не «трубу для данных», а контракт между транзакционной системой и всей остальной платформой.
Для русскоязычной аудитории тут особенно ценно то, что DoorDash не продает серебряную пулю. Авторы не утверждают, что WAIL должен заменить CDC везде и всем. Скорее они показывают границу применимости стандартного подхода. Если у команды одна-две базы, умеренный поток событий и понятный набор консьюмеров, готовые CDC-инструменты по-прежнему выигрывают по стоимости владения. Но если бизнес держится на высокой частоте изменений, а сбой одного коннектора может выбить половину операционного контура, то проектировать нужно уже не только доставку состояния, но и доставку намерения. Для платформенных инженеров это хороший повод пересмотреть, какие именно события они распространяют, где у них рождается истина и можно ли восстановить бизнес-действие без хрупкой зависимости от конкретного снимка строки в БД.
Отдельно цепляет и операционный подтекст доклада. DoorDash фактически говорит: надежность CDC упирается не в магию движка, а в инженерную дисциплину вокруг него. Наблюдаемость, recoverability, понятные контракты между продьюсерами и консьюмерами, снижение связности между записью в базу и публикацией событий — все это звучит менее эффектно, чем очередной «единый data plane», но именно здесь обычно и скрывается разница между системой, которая переживает пятничный пик заказов, и системой, которую потом чинят всей сменой.
Главный вопрос после такого кейса не в том, появится ли завтра еще один внутренний фреймворк под новым названием. Интереснее другое: сколько компаний, которые годами строили интеграции вокруг логов изменений БД, в ближайшие годы тоже начнут выносить в отдельный слой именно бизнес-intent, а не только raw state. Если этот сдвиг закрепится, архитектура CDC перестанет быть сугубо инфраструктурной темой и окончательно станет частью продуктовой надежности. Подробнее о докладе — .