Технології та Інфраструктура → Latency і оптимізація відгуку API
Latency і оптимізація відгуку API
1) Що таке «latency» і чому це важливо
Latency - сумарна затримка запиту: мережа (DNS + TCP + TLS + RTT), балансер/шлюз, додаток, БД/кеші/черги, зовнішні інтеграції. Для бізнесу критичні P95/P99, а не середнє: саме «хвіст» руйнує UX, CR і SLO.
Базові SLI:- 'SLI _ latency _ P95 = P95 (час _ відгуку)'за 5/30 хвилин
- 'SLI _ latency _ P99 = P99 (час _ відгуку)'
- 'SLI _ queue _ time = P95 (час _ в _ черзі _ воркера)'
- 'SLI _ ext _ call _ P95 = P95 (латентність _ зовнішніх _ провайдерів)'
2) Карта джерел затримок (і куди копати)
1. Мережа та протоколи: DNS, TCP handshakes, TLS, head-of-line (HTTP/1. 1), втрата пакетів, BBR/ECN.
2. Шлюз/балансер: повільні health-check, невалідні таймаути, гарячі поди.
3. Додаток: блокування, GC/stop-the-world, синхронні I/O, contention.
4. Сховища: повільні запити БД, відсутність індексів, холодні сторінки.
5. Зовнішні сервіси: PSP/KYC, сторонні API (вузькі SLA).
6. Черги та фонові джоби: перенавантажені воркери, немає backpressure.
7. Кеш/edge: промахи кешу, слабкий TTL, невалідна інвалідація.
3) Мережа та протоколи
3. 1 DNS/TCP/TLS
DNS prefetch/preconnect на фронті, довгоживучі IP до PSP.
Keep-Alive/connection pooling в клієнтах; на сервері - агрегуйте з'єднання.
TLS: resumption/Session Tickets, сучасний пакет шифрів; уникайте 0-RTT для небезпечних ідемпотентних операцій.
TCP: вимкніть Nagle ('TCP _ NODELAY') для чатів/малих пакетів; tune'initial window', увімкніть BBR де доречно.
3. 2 HTTP/2 и HTTP/3
HTTP/2: мультиплексування зменшує HOL-блокування HTTP/1. 1; слідкуйте за пріоритетами потоків.
HTTP/3/QUIC: нижче вплив втрат/RTT; корисно на мобільній/міжнародній мережі.
Header compression: HPACK/QPACK, але зберігайте розумний розмір заголовків.
3. 3 Балансування/роутинг
Locality-aware (зональність), EWMA/least-request проти «гарячих» інстансів.
Залипання сесій - тільки якщо є state; інакше stateless + загальний кеш/сесії.
4) Формати, корисне навантаження, компресія
Стискайте: Brotli (текст), Gzip як fallback; бінарні формати: Protobuf/Avro для gRPC/внутрішніх API.
Зменшуйте payload: вибіркові поля ('fields =...'), пагінація, умовні GET (ETag/If-None-Match), delta-відповіді.
GraphQL: persisted queries, заборона «жирних» фрагментів, ліміти глибини і складнощів.
Уникайте N + 1: джойни/прекомпозиція, батч-ендпоінти для агрегатів.
5) Таймаути, ретраї, ідемпотентність
Таймаути по ланцюжку: клієнт <шлюз <аппа <сховище/зовнішній виклик.
Ретраї з backoff + jitter, тільки для тимчасових помилок; виставляйте budgets на ретраї.
Ідемпотентність: ключ/токен запиту + збереження результату; ретраї не повинні дублювати операції (особливо фінанси).
Circuit Breaker: відкривайте при деградації; hedged/backup requests для «хвостів» (відправити дублікат через P95).
6) Черги, асинхронність і backpressure
Не блокуйте синхронний шлях: важкі операції (KYC скани, звітність) - у фон.
Backpressure: обмежуйте споживання з черги, фіксуйте паралелізм.
Batching/coalescing: поєднуйте дрібні операції (наприклад, оновлення балансів з агрегуванням).
Outbox/Inbox: гарантована доставка подій при відмовах.
7) Додаток: рантайми і пули
Пули з'єднань до БД/кешів/НТТР; лімітуйте їх, щоб не «задушити» бекенд.
JVM: профілюйте GC (G1/ZGC), уникайте великих алокацій; .NET - ThreadPool/async; Node. js - не блокуйте event loop, винесіть CPU-важке.
Python: асинхронні драйвери (asyncpg/httpx), uvloop; CPU-завдання через worker-pool.
Warm-up: прогрівайте JIT/кеші, «warm pools» інстансів до піків.
8) Бази даних і кеші
Індекси та плани: регулярний'EXPLAIN', авто-вакуум/аналіз, ліміт сканів.
Connection pooling (PgBouncer/Multiplexing), короткі транзакції.
Кеш-стратегії: read-through, write-through/write-behind; TTL + інвалідація по подіям.
Шардинг/репліки: читання зі слейвів, «гарячі ключі» - локальні кеші (near-cache).
9) Кешування та edge
CDN/edge для статик/каталогів, кеш API-відповідей (якщо безпечно) по'Cache-Control','ETag'.
Stale-while-revalidate і stale-if-error для UX-стійкості.
Geo-розподіл: найближчий РОР/регіон знижує RTT.
10) Архітектурні патерни проти хвостів P99
Hedged requests: дублюйте повільний запит на інший інстанс після порога.
Request collapsing: один «ведучий» запит до БД, інші чекають результат (уникає штормів).
Prioritization: VIP/критичні операції - виділений пул/пріоритет.
Graceful degradation: урізайте другорядні поля/віджети при перевантаженні.
11) Конфіги (приблизно)
11. 1 NGINX (таймаути/компресія)
nginx proxy_connect_timeout 1s;
proxy_send_timeout 2s;
proxy_read_timeout 2s;
send_timeout 2s;
gzip on;
gzip_types application/json text/plain text/css application/javascript;11. 2 Envoy (hedge + retry budget)
yaml
RetryPolicy:
retry_on: 5xx,reset,connect-failure num_retries: 2 per_try_timeout: 300ms retry_back_off: { base_interval: 50ms, max_interval: 200ms }
retry_priority:
name: envoy. retry_priorities. previous_priorities
HedgePolicy:
hedge_on_per_try_timeout: true initial_requests: 1 additional_request_chance: 0. 211. 3 gRPC (клієнт)
json
{
"methodConfig": [{
"name": [{"service": "payments. Service"}],
"timeout": "0. 8s",
"retryPolicy": {
"maxAttempts": 3,
"initialBackoff": "0. 05s",
"maxBackoff": "0. 2s",
"backoffMultiplier": 2. 0,
"retryableStatusCodes": ["UNAVAILABLE","DEADLINE_EXCEEDED"]
}
}]
}12) Observability: міряйте правильно
RED/USE метрики + трейси OTel: 'trace _ id'крізь шлюз-сервіс-БД-зовнішні API.
Окремі мітки: `api_version`, `region`, `partner`, `endpoint`.
Дашборди: P50/P95/P99, queue time, error mix, retry rate, cache hit.
Synthetics з цільових країн/ASN (TR/BR/EU) і по критичних шляхах (reg→depozit, payout).
- Core API: 'P95 ≤ 250ms','P99 ≤ 500ms'( 30 днів)
- PSP webhook обробка: 'P99 ≤ 60s'з ретраями
- Freshness каталогу: 'P95 лаг ≤ 30s'
13) FinOps и latency
Мілісекунди коштують грошей: оцініть $/мс виграшу в CR/ARPPU.
Right-sizing: швидше ≠ дорожче завжди; грамотний кеш/формати дешевять і прискорюють.
Egress/edge: CDN зменшує RTT і вартість вихідного трафіку з регіону.
14) Чек-лист оптимізації (покроково)
1. Поставте SLO і заміряйте хвости (P95/P99) по ендпоінтах/регіонах/партнерам.
2. Увімкніть HTTP/2/3, TLS resumption, довгоживучі з'єднання.
3. Стисніть і схудніть відповіді: Brotli/Gzip, поля за запитом, пагінація, ETag.
4. Налаштуйте таймаути/ретраї/брейкери; додайте ідемпотентність.
5. Кеш/edge: hit-rate і правильні TTL; stale-режими.
6. БД: індекси, плани, пули, репліки; усуньте N + 1.
7. Асинхроньте важке: черги, батчинг, backpressure.
8. Hedge/collapse/priority для критичних шляхів.
9. Warm-up і предиктивний скейлінг до піків (турніри/матчі).
10. Синтетика і алерти на P99 і queue time; регулярні перф-рев'ю.
15) Анти-патерни
Один глобальний таймаут «на все» і безконтрольні ретраї (DDOS самого себе).
Залипання сесій без необхідності → гарячі ноди.
Великі JSON без компресії і фільтрів полів.
Синхронні виклики до повільних зовнішніх API в «гарячому шляху».
Відсутність індексів/лімітів в БД; N + 1 в ORM.
Немає кешу/edge і ETag; постійні повні відповіді.
Мікс бізнес-і технічних помилок в одну «ретраящуюся» кошик.
16) Контекст iGaming/фінтех: Практичні ноти
Reg→depozit (CR): пріоритет маршрутів, окремий пул,'P99 ≤ 500ms'; деградація - відключати «прикраси» UI.
PSP-інтеграції: ліміти конкарренсі, ретраї за часовими кодами, warm-коннекти, регіональні egress-IP.
VIP-операції: гарантований пул/пріоритет, обхід загальних черг.
Турніри/івенти: предиктивний скейл, прогрівши кешею, prefetch.
Звітність: async і SLA на freshness, не блокує прод-шлях.
Підсумок
Оптимізація latency - це дисципліна балансу: мережа (HTTP/2/3, TLS), протоколи і кеш, таймаути/ретраї з ідемпотентністю, БД/кеші, асинхронні патерни і спостережуваність P95/P99. Сфокусувавшись на хвостах і усунувши «вузькі горлечка», ви стабілізуєте відгук, поліпшите конверсію і знижуєте вартість мілісекунди - там, де це дійсно впливає на бізнес.