Уявіть: ваш API обробляє 10 000 запитів на секунду, бекенд ледве справляється, а половина відповідей — одні й ті самі дані. Кешування API Gateway забезпечує значне прискорення API без зміни коду сервісів. У реальному проєкті кешування на gateway дозволило знизити навантаження на бекенд у 5 разів, а час відповіді — у 10 разів. Економія інфраструктури сягає $5000 на місяць для середнього проєкту. Ми впроваджуємо кеш на шлюзі (Kong, Nginx, AWS) та знижуємо навантаження на бекенд на 30–70%. Після налаштування hit rate досягає 95%. У цій статті — практика, підкріплена 5+ роками досвіду на 50+ проєктах.
Чому кешування на gateway вигідніше, ніж на бекенді?
Кеш на рівні gateway перехоплює запит до того, як він досягне сервісу. Бекенд взагалі не отримує навантаження для кешованих запитів. На бекенді кеш часто ускладнює логіку та потребує доопрацювання кожного сервісу. Gateway ж — єдина точка конфігурації: додав плагін або директиву nginx — і готово. Для Kong використовуйте плагін Kong proxy-cache, для Nginx — директиву proxy_cache, для AWS — вбудоване кешування API Gateway. Економія на інфраструктурі досягає 40%, що в 2 рази краще, ніж традиційне кешування на бекенді.
| Критерій | Gateway-кеш | Бекенд-кеш |
|---|---|---|
| Навантаження на сервіси | Нульове для кешованих запитів | Повне (запит доходить до сервісу) |
| Складність впровадження | Одне налаштування (плагін/конфіг) | Потребує змін у кожному сервісі |
| Єдина точка керування | Так | Ні (розподілена конфігурація) |
| Продуктивність | До 100 000 RPS на Nginx | Залежить від реалізації |
Які ендпоінти кешувати, а які ні?
Кешувати безпечно:
-
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 залежно від розміру кластера.
| Шлюз | Стратегія кешу | Інвалідація | Продуктивність |
|---|---|---|---|
| Kong | memory/redis | Admin API | ~50 000 rps на інстанс |
| Nginx | disk | purge module | ~100 000 rps |
| AWS REST | in-memory | Cache-Control | ~10 000 rps (залежить від розміру) |
Розширені стратегії кешування
Крім базових налаштувань, використовуйте заголовки Vary (наприклад, Vary: Accept-Encoding для стиснення), ETag для умовних запитів, Surrogate-Key (Kong) для тег-базової інвалідації. Також ефективні prefetching і cache warming для критичних ендпоінтів.
Як уникнути кеш-шторму?
При істеченні TTL популярного ключа десятки воркерів одночасно рвуться в upstream — це cache stampede. Три способи захисту:
-
Mutex/lock: тільки один запит оновлює кеш, решта чекають (наприклад,
proxy_cache_lock onв Nginx). - Probabilistic early expiration: оновлюємо кеш трохи раніше TTL з імовірністю, що зростає до строку істечення.
- Stale-while-revalidate: віддаємо стару відповідь, поки йде оновлення (реалізовано вище). Паттерн stale-while-revalidate допомагає уникнути cache stampede, знижуючи навантаження на бекенд у 3 рази.
Інвалідація — головний біль кешування. Найнадійніший спосіб — використовувати версіонування ресурсів (наприклад, /api/v2/products замість ?version=2). Якщо версіонування неможливе, застосовують:
- Purge-запити (Nginx purge, Kong Admin API).
- Встановлення короткого TTL і паралельне оновлення (stale-while-revalidate).
- Tag-based інвалідацію (наприклад, через Surrogate-Key в Kong).
Не використовуйте глобальне очищення кешу без крайньої потреби — це викличе cache stampede.
Детальніше про метрики продуктивності
У реальному проєкті з 20 сервісами середній hit rate склав 95%, а економія інфраструктури — $5000/місяць. Після впровадження stale-while-revalidate на Nginx вдалося знизити пікове навантаження в 3 рази.Процес роботи
- Аналіз: аудит ендпоінтів, виявлення кандидатів на кеш.
- Проєктування: вибір стратегії, ключа кешу, TTL, способу інвалідації.
- Реалізація: налаштування gateway, написання Terraform/Ansible при необхідності.
- Тестування: замір hit ratio, перевірка коректності для авторизованих запитів.
- Моніторинг: дашборди з hit rate, розміром кешу, кількістю промахів.
Що входить у роботу
- Налаштування кешування для вибраних роутів.
- Документація з інвалідації та моніторингу.
- Навчання команди (1–2 години).
- Гарантія коректної роботи протягом місяця.
Зв'яжіться з нами для консультації — оцінимо ваш проєкт за один день. Понад 5 років досвіду та 50+ успішних впроваджень гарантують результат. Орієнтовна вартість налаштування — від $500 до $2000 залежно від складності. Замовте налаштування кешування та отримайте результат за 1–5 днів.