API Rate Limiting та Usage Tracking для SaaS

Ми не раз бачили, як один агресивний клієнт клав інфраструктуру через відсутність rate limiting. В одному проєкті 5% користувачів генерували 80% трафіку, що призводило до падіння latency з 20 ms до 2000 ms і втрати клієнтів — середній збиток склав $30 000 на рік при 1000 користувачах. Без точного обліку використання неможливо побудувати справедливу тарифікацію. Наш досвід показує, що правильно налаштоване рішення підвищує стабільність і прозорість білінгу. Середня економія на хмарних ресурсах після впровадження usage tracking становить $2 500 на місяць. Rate limiting — базовий захист бекенду. Зв'яжіться з нами, щоб запобігти подібним інцидентам.

Чому rate limiting — основа стабільності SaaS?

Без обмежень один клієнт здатен вичерпати ліміти downstream-сервісів за хвилини. Rate limiting захищає інфраструктуру, запобігає DDoS і скрейпінгу. Usage Tracking, своєю чергою, дає базу для тарифікації за моделлю pay-per-use — без точних даних неможливо виставити рахунок або перевірити коректність планів.

Як вибрати алгоритм для вашого API?

Обмеження вибудовуються в кілька рівнів: за IP, за API-ключем або JWT-токеном, за endpoint. Для кожного рівня підходить свій алгоритм. Порівняємо основні:

Token Bucket оптимальніший за Fixed Window у сценаріях з burst-трафіком, оскільки клієнт може "накопичувати" токени, але не перевищує середню швидкість. Для більшості SaaS це найкращий вибір.

Як ми впроваджуємо rate limiting в продакшен?

Node.js/Express — бібліотека express-rate-limit з Redis-сховищем через rate-limit-redis:

import rateLimit from 'express-rate-limit';
import RedisStore from 'rate-limit-redis';

const planLimits = { free: 100, pro: 1000, enterprise: 10000 };

const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  limit: (req) => planLimits[req.tenant.plan] ?? 100,
  keyGenerator: (req) => `rl:${req.tenant.id}:${req.path}`,
  store: new RedisStore({ client: redisClient }),
  handler: (req, res) => {
    res.status(429).json({
      error: 'rate_limit_exceeded',
      retryAfter: res.getHeader('Retry-After'),
    });
  },
  standardHeaders: 'draft-7',
  legacyHeaders: false,
});

Заголовки RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset згідно з RFC 6585 обов'язкові — клієнтські SDK використовують їх для back-off.

Python/FastAPI — бібліотека slowapi поверх limits:

from slowapi import Limiter

limiter = Limiter(key_func=lambda req: req.state.tenant_id,
                  storage_uri="redis://localhost:6379")

@app.get("/api/reports")
@limiter.limit("10/minute")
async def generate_report(request: Request):
    ...

Nginx — на рівні reverse proxy для грубого захисту:

limit_req_zone $http_x_api_key zone=api:10m rate=100r/m;
limit_req zone=api burst=20 nodelay;
limit_req_status 429;

Usage Tracking: що і як рахувати

Метрики поділяються на billing (кількість запитів, об'єм даних, активні користувачі) та operational (latency, error rate).

Архітектура збору даних:

1. В middleware атомарно інкрементуємо лічильник в Redis: INCR usage:{tenant_id}:{date}:{endpoint}
2. Celery/BullMQ job кожні 5 хвилин зливає агрегати з Redis в PostgreSQL
3. Детальний лог запитів пишеться асинхронно в ClickHouse або TimescaleDB для аналітики

CREATE TABLE api_usage_daily (
  tenant_id   UUID NOT NULL,
  date        DATE NOT NULL,
  endpoint    VARCHAR(200),
  plan        VARCHAR(50),
  requests    BIGINT DEFAULT 0,
  bytes_in    BIGINT DEFAULT 0,
  bytes_out   BIGINT DEFAULT 0,
  errors_4xx  INT DEFAULT 0,
  errors_5xx  INT DEFAULT 0,
  PRIMARY KEY (tenant_id, date, endpoint)
);

Як забезпечити точність обліку usage?

Для мінімізації втрат даних використовуйте Redis persistence (RDB/AOF) і dead-letter queue для збійних подій. Перевіряйте цілісність щоденним порівнянням агрегатів з raw-логами. У 95% випадків розбіжності усуваються дублюванням ключових операцій.

Dashboard та алерти для клієнтів

Клієнт повинен бачити своє споживання в реальному часі — це знижує кількість несподіваних блокувань та support-тікетів. Мінімальний набір: поточне використання vs квота (progress bar), графік по днях за останні 30 днів, топ-5 endpoints за кількістю викликів. Алерти при досягненні 80% квоти.

Інтеграція з білінгом

При pay-per-use моделі дані передаються в Stripe через Billing Meters API:

await stripe.billing.meters.createEvent({
  event_name: 'api_requests',
  payload: {
    stripe_customer_id: tenant.stripeCustomerId,
    value: requestCount,
  },
  timestamp: Math.floor(Date.now() / 1000),
});

Для фіксованих планів з overage — порівнюємо usage з квотою в кінці періоду та виставляємо додатковий invoice.

Покрокова інструкція з впровадження rate limiting

1. Аналіз поточного трафіку: визначте пікові RPS, типові endpoints та клієнтів.
2. Вибір алгоритму: Token Bucket для burst-навантажень, Fixed Window для простих сценаріїв.
3. Реалізація middleware: інтегруйте обрану бібліотеку з Redis-сховищем.
4. Налаштування заголовків: додайте RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset.
5. Тестування: перевірте поведінку при перевищенні ліміту (очікуйте 429).
6. Моніторинг: налаштуйте алерти на 80% квоти та збір usage-метрик.

Що входить в роботу

При замовленні реалізації ви отримуєте:

• Вихідний код middleware rate limiting з обраним алгоритмом
• Налаштовану систему збору usage-метрик на Redis + PostgreSQL
• Dashboard для клієнтів (кастомний або на базі Grafana)
• Документацію з API (OpenAPI) з прикладами відповідей 429
• Інтеграцію з вашою білінговою системою (Stripe, Chargebee та ін.)
• Гарантію стабільності: рішення проходить навантажувальне тестування до 10 000 RPS

Ми впровадили rate limiting для 20+ продуктів — від стартапів до платформ з аудиторією від 10 000 користувачів. Замовте впровадження rate limiting для вашого SaaS та отримайте консультацію архітектора. Щоб обговорити деталі, зв'яжіться з нами.

Типові терміни

Конкретна вартість розраховується індивідуально після аналізу архітектури та навантаження.

Розробка 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 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.