Шесть месяцев пролетели как один день. Стартап "Bookshelf" вырос из скромного MVP в полноценную платформу с тысячами пользователей. В первом проекте вы построили монолит, во втором проекте — разрезали его на auth-service и books-service, в третьем проекте — добавили асинхронную обработку обложек через RabbitMQ.

И вот на очередном стендапе frontend-разработчик Дима поднимает руку:

Ребят, у меня в коде уже три разных URL для backend'а. auth-service на 8081, books-service на 8082, ещё этот worker... Каждый раз, когда добавляется новый сервис, мне нужно обновлять конфигурацию. А ещё на каждом запросе я дублирую логику логирования и обработки ошибок. Может, сделаем один вход?

Алексей, основатель стартапа, кивает:

Дима прав. Netflix, Amazon, все большие ребята используют API Gateway — единую точку входа. Клиент знает только один адрес, а gateway сам разбирается, куда направить запрос. Плюс там же можно централизовать rate limiting, кэширование, логирование...

Представьте отель с десятком разных служб: ресторан, спа, прачечная, консьерж. Без ресепшена гость должен знать телефон каждой службы и звонить напрямую. С ресепшеном — один номер, и администратор соединит с нужным отделом. Заодно он проверит, что гость действительно проживает в отеле, и запишет, кто когда звонил.

Ваша задача в этом проекте: создать API Gateway для Bookshelf. К концу проекта у вас будет:

• Единая точка входа для всех клиентов (порт 8000)
• Маршрутизация запросов к backend-сервисам
• Rate limiting для защиты от перегрузки
• Кэширование популярных запросов в Redis
• Дашборд с агрегированными данными из нескольких сервисов
• Централизованное логирование и трейсинг

Это финальный аккорд курса: вы объедините всё, что узнали, в production-ready систему.