Прокси-кеш DoorDash уже обслуживает более 1,5 млн запросов в секунду и, по данным компании, держит доступность на уровне 99,99999%. Для русскоязычных команд, которые живут в микросервисах и устали от повторяющихся запросов между сервисами, это важный сигнал: кэширование снова перестает быть локальной фичей приложения и все чаще переезжает в инфраструктурный слой.
О новой платформе сообщает InfoQ. DoorDash описывает Entity Cache как прозрачный прокси-кеш, встроенный в сервисную mesh на базе Envoy и Valkey. Он перехватывает HTTP- и gRPC-запросы до того, как они доходят до upstream-сервисов, проверяет наличие валидного ответа в кэше и, если находит попадание, отдает результат сразу. Если в кэше пусто, запрос уходит дальше по цепочке, а полученный ответ сохраняется по заданным политикам. Для прикладных команд в этом подходе есть приятный бонус: менять код сервисов не нужно, существующие вызовы остаются как есть, а правила кэширования управляются централизованно.
Проблема, которую DoorDash решал, знакома почти любой крупной платформе. Когда микросервисов становится много, сервисы начинают дергать друг друга за одни и те же данные, которые читаются часто, а меняются редко. Система при этом вроде бы работает, но backend получает лишнюю нагрузку, вычислительные ресурсы утекают в трубу, а хвостовые задержки растут именно там, где бизнесу потом больнее всего. DoorDash пишет, что Entity Cache уже поддерживает более 100 эндпоинтов в 50 сервисах. Это не лабораторная игрушка для одной команды, а общий слой для внутреннего трафика, который компания пытается превратить в стандарт по умолчанию.
Важно и то, что компания не подает Entity Cache как «еще один кэш». В описании это набор связанных механизмов: собственно кэширование, инвалидация, обработка сбоев, координация запросов и оптимизации производительности. Самая тонкая часть здесь, конечно, свежесть данных. DoorDash использует событийную инвалидацию на Kafka: вместо распределенного удаления записей из кэша система сравнивает timestamps обновлений с тем, что лежит в кэше, и решает, нужно ли обновить ответ. Плюс у платформы есть двойные пороги TTL. Это позволяет в штатном режиме держать данные свежими, а при авариях некоторое время отдавать слегка устаревшие, но все еще допустимые ответы. Подход не новый по идее, но в проде именно такие скучные компромиссы обычно и спасают сервисы от красивого падения.
DoorDash отдельно подчеркивает, что эта схема пригодилась во время многочасового сбоя upstream-сервиса. Вместо того чтобы синхронно уронить зависимые сервисы, Entity Cache продолжал обслуживать запросы из кэша и отдавал устаревшие, но валидные данные. Если кэш-инстанс становился нездоровым, Envoy исключал его из маршрутизации и направлял трафик напрямую в upstream. Для инженеров это, пожалуй, ключевой момент всей истории: кэш здесь работает не только как ускоритель, но и как буфер отказоустойчивости. И это уже совсем другой разговор, чем банальное «давайте сократим latency».
Чтобы выдерживать такой объем трафика, DoorDash пришлось копать и в низкоуровневую механику. Компания пишет, что использовала собственные buffer pools, чтобы снизить накладные расходы на выделение памяти. Еще один элемент — lock-free single-flight-механизм, который не дает нескольким одинаковым запросам одновременно выполнять одну и ту же работу при промахе кэша. Сверху добавили вероятностное раннее обновление по алгоритму XFetch: популярные записи обновляются до истечения срока жизни, чтобы толпа запросов не встретила просроченный кэш в одну и ту же миллисекунду. В переводе на язык эксплуатации это борьба с двумя вечными врагами распределенных систем: лишней аллокацией и stampede-эффектом, когда кэш формально есть, но пользы от него в самый неудобный момент уже нет.
Цифры выглядят серьезно даже по меркам больших backend-платформ. DoorDash утверждает, что эти оптимизации снизили скорость аллокаций на 50–60%, увеличили пропускную способность одного pod примерно в пять раз и уменьшили всплески P99 latency до 80%. Cache hit rate, по словам компании, превышает 90%, количество запросов к upstream-сервисам в нормальном режиме сокращается на 60–95%, а для новых эндпоинтов задержка может падать до 90%. При этом собственный overhead прокси на P99 составляет около 2,1 мс. Для тех, кто когда-либо спорил о том, стоит ли встраивать еще один слой между сервисами, ответ здесь довольно прагматичный: стоит, если этот слой не превращается в узкое место и снимает с верхних уровней кратно больше боли, чем добавляет снизу.
Для российского рынка и вообще для команд, которые строят B2C-платформы, маркетплейсы, финтех или логистику, кейс DoorDash интересен не потому, что «у них большой масштаб и нам так не надо». Как раз надо смотреть на архитектурный паттерн. Чем больше сервисов, тем хуже работает привычка решать кэширование локально в каждом приложении. Получается зоопарк библиотек, разные TTL, разные правила инвалидации и неизбежные споры о том, почему один сервис уже видит новые данные, а другой еще живет в прошлом. Прозрачный инфраструктурный кэш убирает часть этой самодеятельности и делает поведение системы предсказуемее. Цена вопроса, конечно, тоже понятна: нужно инвестировать в сервисную mesh, наблюдаемость, дисциплину схем данных и аккуратную модель консистентности. Иначе централизованный кэш станет централизованной проблемой, а это уже совсем не тот KPI, который хочется показать на постмортеме.
На этом фоне особенно заметен общий тренд: крупные платформы все чаще выносят производительные и отказоустойчивые механизмы из прикладного кода в стандартные инфраструктурные прослойки. DoorDash со своим Entity Cache здесь не изобретает новую физику, но довольно убедительно показывает, что следующий раунд конкуренции в микросервисной архитектуре идет не за количеством сервисов, а за тем, насколько умно они общаются друг с другом. Детали кейса можно проверить в материале .
