API Gateway в Авито: как роутинг между тысячами сервисов превращается в инженерный продукт

Автор: Александр Данковцев · HighLoad++

Александр Данковцев — Lead Engineer команды Antimonolith в Авито. Команда занимается тем, что помогает сотням сервисов взаимодействовать друг с другом не хаотично, а по правилам. Доклад с HighLoad++ 2024 — про API Gateway как ключевой элемент этой архитектуры.

API Gateway — одно из тех решений, которые выглядят просто («просто обратный прокси с маршрутизацией»), пока вы не начинаете масштабировать. В Авито тысячи микросервисов, сотни команд и постоянно меняющиеся API. Данковцев рассказывает, как Gateway эволюционировал от простого роутера до полноценного инфраструктурного продукта: с собственным языком конфигурации, валидацией, rate limiting, auth-интеграцией и observability. Ключевая мысль: когда Gateway становится платформой, а не конфигом nginx, он начинает требовать того же инженерного внимания, что и любой другой продукт — владельца, versioning, обратной совместимости.

Кому смотреть: архитекторам и техлидам, которые строят или унаследовали API Gateway в системе с более чем десятком сервисов — особенно тем, у кого роутинг пока «просто конфиг».

Из этого можно взять в работу: посмотрите на ваш текущий API Gateway как на продукт: есть ли у него владелец, changelog, способ добавить новый маршрут без ручного merge конфига? Если нет — вы уже несёте технический долг, который растёт с каждым новым сервисом.

Данковцев начинает с истории: первый API Gateway в Авито появился как необходимость, а не как дизайн-решение. Когда число сервисов перевалило за несколько десятков, маршрутизация через nginx-конфиги вручную стала узким местом и источником ошибок. Команды ждали деплоя инфраструктурщиков, чтобы добавить один новый endpoint.

Переход к декларативной конфигурации стал первым важным шагом: каждый сервис описывает свои маршруты в yaml-манифесте, Gateway читает эти манифесты и собирает итоговую конфигурацию автоматически. Это убирает человека из критического пути и позволяет командам деплоить роутинг самостоятельно.

Следующая проблема — безопасность и качество API. Когда любая команда может объявить любой маршрут, нужен механизм валидации: нет ли конфликтов с существующими путями, соответствуют ли заголовки принятым стандартам, прошёл ли сервис auth-интеграцию. В Авито для этого построили pipeline проверок, который срабатывает перед тем, как новый маршрут попадает в продакшн.

Auth в Gateway — отдельная тема. Централизованная проверка токенов на уровне Gateway снимает нагрузку с каждого отдельного сервиса, но требует аккуратной работы с контекстом запроса: идентификатор пользователя, роли, scope нужно передавать дальше в заголовках без потерь. Данковцев разбирает, как это реализовано и какие ловушки здесь встречались.

Rate limiting: простой подход — лимит по IP — в распределённой системе работает плохо. Авито использует лимиты по API-ключам и пользователям с distributed счётчиками, что требует Redis-кластера в критическом пути каждого запроса. Данковцев честно говорит о latency overhead этого решения и о том, как его минимизируют.