Що таке API Gateway та для чого він потрібен?

🚪 Що таке API Gateway простими словами

API Gateway — це окрема технологія. Архітектурний патерн: один сервер який приймає всі зовнішні запити і вирішує що з ними робити далі.

Визначення: API Gateway — це проміжний шар між клієнтами (web, mobile, партнерські інтеграції) і вашими внутрішніми сервісами. Клієнт не звертається напряму до мікросервісів — він звертається до gateway, а той вже вирішує куди передати запит, перевіряє чи має клієнт право на цю дію, і повертає відповідь у потрібному форматі.

Чому він з'явився

Десять років тому типовий backend був монолітом — одним великим застосунком який обробляв усі запити. Клієнту не треба було думати "куди йти" — endpoint був один.

Коли компанії почали дробити моноліт на мікросервіси — User Service, Order Service, Payment Service, Notification Service — виникла нова проблема. Клієнт (мобільний застосунок чи фронтенд) тепер мусив знати адреси десятків сервісів, кожен з власною логікою аутентифікації, власним форматом помилок, власною версією API.

API Gateway розв'язав цю проблему просто: клієнт знову бачить один endpoint, а вся складність розподіленої системи ховається за ним.

Чим це відрізняється від звичайного backend endpoint

Тут часто виникає плутанина. Звичайний backend endpoint — це конкретна бізнес-логіка: POST /orders створює замовлення, GET /users/123 повертає дані користувача. Endpoint знає що робити з даними.

API Gateway — навпаки. Він не знає і не повинен знати бізнес-логіку. Його завдання — прийняти запит, перевірити токен, визначити куди його маршрутизувати, можливо об'єднати відповіді з кількох сервісів — і віддати результат. Якщо в коді gateway з'являється бізнес-логіка на кшталт "якщо сума замовлення більше 1000 — застосувати знижку" — це сигнал що архітектура ламається. Це найчастіша помилка яку я бачу в реальних проектах: команда поступово перетворює gateway на ще один моноліт, тільки тепер критичний для роботи всієї системи.

🏗️ Чому мікросервісам потрібен API Gateway

Уявіть реальний проект: e-commerce платформа з 20 мікросервісами. Mobile-застосунок хоче показати сторінку профілю користувача — а для цього потрібні дані з User Service, історія замовлень з Order Service, статус останньої оплати з Payment Service і список непрочитаних сповіщень з Notification Service.

Без API Gateway клієнт мусить:

• Знати IP-адреси або домени всіх 4 сервісів
• Реалізувати аутентифікацію окремо для кожного — а якщо у кожного своя логіка перевірки токена, це 4 різні реалізації одного й того ж
• Зробити 4 окремих HTTP-запити і самостійно об'єднати відповіді на клієнті — що означає 4 round-trip замість одного, повільніше завантаження на мобільному інтернеті
• Якщо Order Service переїде на нову адресу або змінить версію API — оновлювати клієнтський застосунок, а на мобільних платформах це означає чекати поки користувачі оновлять застосунок з App Store

Кожна з цих проблем сама по собі вирішувана. Але разом вони перетворюють розробку клієнта на постійну боротьбу з інфраструктурою замість роботи над продуктом.

Архітектура без gateway:

Mobile App ──┬──→ User Service
             ├──→ Order Service
             ├──→ Payment Service
             └──→ Notification Service

Архітектура з API Gateway:

Mobile App
    │
    ▼
API Gateway
    │
    ├──→ User Service
    ├──→ Order Service
    ├──→ Payment Service
    └──→ Notification Service

Різниця виглядає невеликою на схемі — але на практиці вона означає що клієнт робить один запит до /profile, а gateway вже сам ходить у чотири сервіси, об'єднує відповіді і повертає готовий результат.

Хто реально це використовує

Це не теоретична архітектура з підручника. Найбільші технологічні компанії світу побудовані саме так:

• Netflix — розклав моноліт на сотні мікросервісів, кожен з яких (кодування відео, рекомендації, відтворення) масштабується незалежно. Через свій gateway Zuul Netflix обробляє мільярди запитів щодня. Цікавий факт: саме Netflix відкрили вихідний код Eureka — сервісу про який розповім нижче.
• Amazon — модель "команда на дві піци" (two-pizza team), де кожна невелика команда повністю володіє своїм мікросервісом від коду до production. Саме це дозволило Amazon вирости від книжкового магазину до мультитрильйонної платформи.
• Uber — сервіси поїздок, водіїв, ціноутворення і диспетчеризації працюють незалежно по всьому світу. Uber побудував межі сервісів навколо бізнес-доменів (Domain-Driven Design) саме щоб уникнути "розподіленого моноліту" — ситуації коли у вас формально мікросервіси, але вони настільки тісно зв'язані що деплоїти доводиться все одразу.
• Spotify — у 2026 році оперує понад 1500 мікросервісами для даних, рекомендацій, відтворення і реклами, організованими за моделлю "squad, tribe, chapter, guild" де невеликі автономні команди володіють сервісами від початку до кінця.

Важливий нюанс який варто знати перед тим як кидатись будувати 50 мікросервісів: Amazon Prime Video у 2023 році частково відкотився назад до моноліту для свого сервісу моніторингу якості відео — об'єднавши кілька розподілених компонентів в один процес. Причина — надмірні витрати на оркестрацію між сервісами через AWS S3 і Lambda. Результат: зниження інфраструктурних витрат більш ніж на 90%. Це не доказ що мікросервіси "погані" — це доказ що архітектура має відповідати конкретній задачі, а не бути карго-культом просто тому що "так роблять великі компанії".

Що відбувається коли один з сервісів падає

Тут виникає природне запитання: а що якщо Order Service впаде? Невже весь профіль користувача стане недоступний?

У production-системах кожен сервіс зазвичай запускається не в одному екземплярі, а в кількох — це називається горизонтальне масштабування. Наприклад замість одного Order Service у вас є три однакових інстанси: order-service-1, order-service-2, order-service-3 — кожен на своєму сервері або в своєму контейнері.

API Gateway
    │
    ├──→ order-service-1  (healthy)
    ├──→ order-service-2  (упав)
    └──→ order-service-3  (healthy)

Якщо order-service-2 падає — gateway (точніше, його load balancer) це помічає через health check і просто перестає відправляти туди трафік. Запити йдуть тільки на order-service-1 і order-service-3, користувач взагалі не помічає що щось трапилось. Коли впалий інстанс відновлюється — він знову повертається в ротацію.

Це і є одна з головних практичних причин чому варто платити складністю за мікросервіси: відмова одного інстансу не означає відмову всієї системи. У моноліті якщо застосунок впав — впала вся система одразу.

Service Discovery: звідки gateway знає де шукати сервіси

Виникає логічне питання: якщо у вас є три інстанси Order Service і вони можуть з'являтись, падати, переїжджати на нові сервери — як gateway взагалі дізнається їхні актуальні адреси? Жорстко прописувати IP-адреси в конфігурації не варіант — вони постійно змінюються, особливо в Kubernetes чи при автоскейлінгу.

Для цього існує патерн Service Discovery. У своїх Spring Boot проектах я використовував Netflix Eureka — сервіс реєстрації і виявлення сервісів, який Netflix відкрили як open source ще до того як мікросервіси стали мейнстрімом.

Принцип роботи простий:

1. Кожен інстанс сервісу при старті реєструється в Eureka Server — повідомляє "я order-service, моя адреса 10.0.1.15:8082, я живий"
2. Кожні кілька секунд інстанс відправляє heartbeat — підтвердження що він досі живий. Якщо heartbeat не приходить кілька циклів поспіль — Eureka вважає інстанс мертвим і прибирає його зі списку
3. API Gateway (чи будь-який інший сервіс який хоче звернутись до Order Service) питає Eureka: "де зараз живі інстанси order-service?" — і отримує актуальний список

Це знімає з gateway необхідність знати фіксовані адреси сервісів. Замість конфігурації типу "Order Service знаходиться за адресою X" — gateway просто питає реєстр і отримує актуальний список живих інстансів на момент запиту. У Spring Cloud це інтегрується напряму — gateway просто звертається до сервісу за логічним іменем, а Eureka Client під капотом резолвить його в реальну адресу.

Мінуси мікросервісної архітектури і ролі gateway в ній

Чесно кажучи, мікросервіси — це не безкоштовне покращення. Кожна перевага яку ми щойно розглянули має ціну.

Саме тому я раджу клієнтам WebsCraft не впроваджувати мікросервіси і gateway "про запас". Кейс Amazon Prime Video показує: навіть гігант з необмеженими ресурсами повертається до простішої архітектури коли складність розподіленої системи переважає реальну користь. Якщо ваш проект не має чіткої проблеми яку вирішують мікросервіси — простіший моноліт буде надійнішим і дешевшим вибором.

🔄 Як працює API Gateway: життєвий цикл запиту

Щоб зрозуміти gateway не абстрактно а практично — пройдемось по тому що відбувається з одним конкретним запитом від моменту коли він залишає клієнт до моменту коли клієнт отримує відповідь.

Приклад: мобільний застосунок робить запит GET /api/orders/456 щоб показати деталі замовлення.

1. Request — застосунок відправляє HTTP-запит на адресу gateway з заголовком Authorization: Bearer eyJhbGc.... Клієнт не знає і не повинен знати що Order Service насправді розташований на внутрішній адресі order-service.internal:8082.
2. Authentication — gateway перехоплює запит до того як він дійде до будь-якого бізнес-сервісу. Перевіряє підпис JWT-токена, термін дії, витягує user_id з payload. Якщо токен невалідний — запит відхиляється тут же, з кодом 401, навіть не торкаючись Order Service. Це критично: внутрішні сервіси можуть взагалі не мати логіки перевірки токенів — вони довіряють що якщо запит дійшов до них, він вже пройшов gateway.
3. Routing — на основі шляху /api/orders/456 gateway визначає що цей запит має йти в Order Service. Правило маршрутизації зазвичай виглядає просто: все що починається з /api/orders йде на конкретний внутрішній адрес.
4. Processing — gateway передає запит в Order Service вже з контекстом користувача (наприклад в заголовку X-User-Id: 789). Order Service не парсить JWT самостійно — він просто довіряє заголовку який поставив gateway. Order Service обробляє бізнес-логіку: знаходить замовлення в базі даних, перевіряє чи належить воно цьому користувачу, повертає дані.
5. Response — gateway отримує відповідь від Order Service, можливо застосовує трансформацію формату (наприклад прибирає внутрішні поля які не повинні бути видимі клієнту), і повертає фінальний JSON мобільному застосунку.

Весь цей цикл займає мілісекунди і для клієнта виглядає як один простий HTTP-запит. Складність розподіленої системи — авторизація, маршрутизація, внутрішні адреси сервісів — повністю прихована за gateway.

⚙️ Основні функції API Gateway

Розберемо п'ять функцій які зустрічаються в практично кожному production-розгортанні API Gateway — від невеликого стартапу до Netflix-масштабу.

Маршрутизація запитів (Routing)

Базова функція: визначити куди передати запит на основі URL-шляху, HTTP-методу або заголовків. У production-конфігурації Kong чи NGINX це виглядає приблизно так:

routes:
  - path: /api/users/*
    service: user-service
    port: 8081
  - path: /api/orders/*
    service: order-service
    port: 8082
  - path: /api/payments/*
    service: payment-service
    port: 8083

На перший погляд — просто проксі. Але на практиці маршрутизація дозволяє робити речі недоступні звичайному reverse proxy: canary deployment коли 95% трафіку йде на стару версію сервісу а 5% — на нову (для тестування без ризику для всіх користувачів), або A/B тестування через заголовки запиту.

Авторизація та перевірка JWT

Це, мабуть, найважливіша причина чому команди взагалі впроваджують gateway. Без нього кожен з 20 мікросервісів повинен мати власну логіку перевірки токенів — а це означає 20 місць де можна зробити помилку в критичному для безпеки коді.

З gateway — перевірка відбувається один раз, в одному місці. Внутрішні сервіси отримують вже перевірений контекст користувача і можуть зосередитись на бізнес-логіці замість безпеки.

Rate Limiting

Захист від зловживань — навмисних (DDoS, скрапінг) і ненавмисних (баг у клієнтському коді який спамить запитами). Типове правило: не більше 100 запитів за хвилину з одного API-ключа. Без gateway цю логіку довелось би дублювати в кожному сервісі окремо — або, що частіше трапляється в реальності, не реалізовувати взагалі, бо "хтось інший мабуть це вже зробив".

Логування та моніторинг

Оскільки весь трафік проходить через одну точку — gateway стає природним місцем для централізованого логування. Замість того щоб шукати причину помилки по логах 20 різних сервісів, можна побачити весь шлях запиту в одному місці: яка latency була на кожному кроці, який сервіс відповів з помилкою, скільки часу зайняла авторизація.

Перетворення запитів (Request Transformation)

Іноді клієнту і внутрішньому сервісу потрібні різні формати даних. Mobile-застосунок може очікувати компактний JSON з мінімумом полів (економія трафіку і батареї), а внутрішній сервіс — повертати повний об'єкт з усіма метаданими. Gateway може на льоту видаляти зайві поля, перейменовувати ключі, конвертувати формати — не змушуючи ні клієнт, ні сервіс підлаштовуватись один під одного.

⚖️ API Gateway та Reverse Proxy: у чому різниця

Це питання яке плутає навіть досвідчених розробників — тому що технічно API Gateway є reverse proxy. Але не кожен reverse proxy є API Gateway.

Reverse proxy (наприклад базовий NGINX без додаткових модулів) вирішує одну задачу: приймає запит і пересилає його на бекенд-сервер, приховуючи внутрішню топологію мережі. Це корисно, але це лише фундамент.

Практичний спосіб запам'ятати різницю: reverse proxy відповідає на питання "куди передати запит", а API Gateway відповідає на питання "куди передати запит, хто його надіслав, чи має він право, і як обробити відповідь". Gateway — це reverse proxy плюс шар бізнес-орієнтованих політик поверх нього.

⚠️ Коли API Gateway не потрібен

API Gateway — потужний інструмент, але не безкоштовний. Він додає мережевий хоп (додаткову затримку), нову точку відмови, і компонент який треба підтримувати та масштабувати окремо. Впроваджувати його "про всяк випадок" — поширена помилка яка ускладнює проект без реальної користі.

Gateway, ймовірно, зайвий якщо:

• У вас невеликий проект — лендінг з формою зворотного зв'язку чи MVP з одним backend-сервісом не потребує проміжного шару маршрутизації. Додати gateway тут — це додати складність заради складності.
• У вас моноліт — якщо весь backend це один застосунок (навіть великий), у вас вже є єдина точка входу за визначенням. Gateway вирішує проблему розподіленої системи — якщо системи розподіленої немає, нема що вирішувати.
• У вас проста архітектура з 2-3 сервісами — поріг де gateway починає окупати себе — це зазвичай 5+ незалежних сервісів з різними клієнтами (web, mobile, партнерські API). До цього простіший reverse proxy типу NGINX або навіть прямі виклики покривають потреби без зайвої інфраструктури.
• У команди немає досвіду з DevOps — gateway потребує моніторингу, налаштування high availability, розуміння як він поводиться під навантаженням. Якщо команда ще не впевнено почувається з базовим deployment — додавання критичного інфраструктурного компонента підвищує ризик а не знижує його.

Правило яким я керуюсь у проектах WebsCraft: якщо ви не можете чітко сформулювати яку саме проблему gateway вирішить у вашому конкретному проекті — швидше за все, вам ще рано його впроваджувати. Додайте коли проблема реально з'явиться, а не заздалегідь.

🎯 Висновок

API Gateway вирішує конкретну проблему: коли мікросервісна архітектура зростає, клієнти не повинні носити на собі тягар знання про внутрішню структуру системи. Gateway бере на себе авторизацію, маршрутизацію, rate limiting і моніторинг — звільняючи і клієнтський код, і внутрішні сервіси від дублювання цієї логіки.

Але це не універсальне рішення яке варто додавати в кожен проект за замовчуванням. Якщо у вас моноліт або невелика кількість сервісів — простіша архітектура буде надійнішою і дешевшою в підтримці.

Якщо ж ваш проект вже переріс цей поріг — наступний логічний крок це розуміння того, як саме gateway вписується в реальну мікросервісну архітектуру: де він стоїть відносно Service Mesh, як працює патерн Backend For Frontend (BFF) коли у вас різні клієнти з різними потребами, і які архітектурні помилки найчастіше трапляються при проектуванні gateway в production-системах.

У наступній статті розберемо архітектурні патерни API Gateway та його використання у production-системах.

📚 Читайте також

• Мікросервіси vs Моноліт: порівняння архітектур
• Ollama: локальний AI у 2026 році