System Design Space

    Глава 24

    Обновлено: 9 февраля 2026 г. в 20:31

    API Gateway

    Прогресс части0/21

    Классическая задача: routing, authentication, rate limiting, load balancing, request/response transformation.

    Связанная книга

    Building Microservices

    Sam Newman подробно описывает роль API Gateway в микросервисной архитектуре.

    Читать обзор

    API Gateway — единая точка входа для всех клиентских запросов в микросервисной архитектуре. Это критически важный компонент, который обеспечивает маршрутизацию, безопасность, трансформацию запросов и множество cross-cutting concerns.

    Зачем нужен API Gateway?

    Единая точка входа вместо прямых вызовов к сервисам
    Централизованная аутентификация и авторизация
    Rate limiting и защита от DDoS
    Трансформация запросов/ответов
    API composition и агрегация
    Мониторинг, логирование, трейсинг

    Функциональные требования

    Routing

    • Path-based routing (/users → User Service)
    • Header-based routing (A/B testing)
    • Query parameter routing
    • Weighted routing (canary deployments)

    Security

    • JWT/OAuth2 validation
    • API key management
    • IP whitelisting/blacklisting
    • mTLS для service-to-service

    Rate Limiting

    • Per-user/per-IP лимиты
    • Per-endpoint throttling
    • Burst handling
    • Quota management

    Transformation

    • Request/Response modification
    • Protocol translation (REST → gRPC)
    • Response aggregation
    • Schema validation

    Связанный кейс

    Rate Limiter

    Детальный разбор алгоритмов rate limiting: Token Bucket, Sliding Window.

    Читать кейс

    Нефункциональные требования

    < 10ms added

    Latency

    P99

    100K+ RPS

    Throughput

    на инстанс

    99.99%

    Availability

    SLA

    Horizontal

    Scalability

    stateless

    Высокоуровневая архитектура

    Кликните на клиента для симуляции
    CLIENTS

    Mobile App

    Web App

    Partner API

    IoT Devices

    Load Balancer

    L4/L7

    Gateway 1

    Gateway 2

    Gateway N

    User Service

    Order Service

    Payment Service

    External Services

    Redis(Cache & Rate Limits)
    Config(etcd / Consul)
    Metrics(Prometheus)
    Готов

    Нажмите на клиента или запустите анимацию для визуализации потока запроса

    Active Client
    Processing Gateway
    Target Service

    Ключевые паттерны

    Backend for Frontend (BFF)

    Отдельный API Gateway для каждого типа клиента, оптимизированный под его потребности.

    Backend for Frontend Pattern

    Отдельный BFF для каждого типа клиента

    КЛИЕНТЫ

    Mobile App

    Оптимизирован под мобильные

    Web App

    Полный функционал

    Admin Panel

    Расширенные права

    BFF LAYER

    Mobile App BFF
    Web App BFF
    Admin Panel BFF

    MICROSERVICES

    Users
    Orders
    Payments
    Inventory
    Analytics
    Settings

    API Composition

    Gateway агрегирует данные из нескольких сервисов в один ответ.

    Преимущества:

    • Уменьшение количества round-trips
    • Скрытие внутренней структуры

    Риски:

    • Увеличение latency
    • Сложность обработки ошибок

    Связанная книга

    Release It!

    Michael Nygard — автор паттерна Circuit Breaker и других stability patterns.

    Читать обзор

    Circuit Breaker в Gateway

    Защита от каскадных сбоев при недоступности downstream сервисов.

    Circuit Breaker Simulation

    Паттерн защиты от каскадных сбоев

    CLOSED

    Нормальная работа. Запросы проходят к сервису.

    Failures: 0/3

    State Transitions

    CLOSED
    failures ≥ 3
    OPEN
    timeout 5s
    HALF-OPEN

    Configuration

    Failure Threshold3
    Reset Timeout5s
    Base Failure Rate30%

    0

    Total Requests

    0

    Successful

    0

    Rejected (Fast)

    Recent Requests
    No requests yet

    Fail Fast

    Мгновенный отказ вместо ожидания timeout

    Cascading Prevention

    Защита от распространения сбоев

    Self-Healing

    Автоматическое восстановление через timeout

    Документальный фильм

    Inside Envoy: The Proxy for the Future

    История создания Envoy Proxy и его роль в service mesh экосистеме.

    Смотреть

    Популярные решения

    Kong

    Open Source / Enterprise
    • Plugins ecosystem
    • Lua/Go extensibility
    • Declarative config

    AWS API Gateway

    Managed
    • Lambda integration
    • WebSocket support
    • Pay-per-request

    Envoy

    Open Source
    • L7 proxy
    • Service mesh ready
    • xDS API

    NGINX Plus

    Commercial
    • High performance
    • Native modules
    • Active health checks

    Traefik

    Open Source
    • Auto-discovery
    • Let's Encrypt
    • Kubernetes native

    Apigee (Google)

    Enterprise
    • Analytics
    • Developer portal
    • Monetization

    Советы для интервью

    1. Начните с "почему"

    Объясните, зачем нужен API Gateway: single entry point, security, cross-cutting concerns. Не просто "это стандарт в микросервисах".

    2. Обсудите stateless vs stateful

    Gateway должен быть stateless для горизонтального масштабирования. Состояние (rate limits, sessions) — в Redis/external store.

    3. Рассмотрите single point of failure

    Gateway — критический компонент. Обсудите: multiple instances, health checks, graceful degradation, fallback responses.

    4. Не делайте Gateway слишком "умным"

    Избегайте бизнес-логики в Gateway. Он должен заниматься только cross-cutting concerns: auth, routing, rate limiting.

    Ключевые выводы

    • API Gateway — единая точка входа, обеспечивающая routing, security и observability
    • Должен быть stateless для горизонтального масштабирования (состояние в Redis)
    • Backend for Frontend (BFF) — отдельный gateway для каждого типа клиента
    • API Composition уменьшает round-trips, но добавляет latency и сложность
    • Circuit Breaker защищает от каскадных сбоев downstream сервисов
    • Избегайте бизнес-логики в Gateway — только cross-cutting concerns