Edge обчислення і latency control

1) Навіщо edge і що таке latency control

Edge - це виконання логіки ближче до користувача (PoP, CDN, локальний PoP оператора, 5G MEC). Мета - знизити RTT і «хвости» (p95/p99), розвантажити ядро і забезпечити гео-дотримання правил.
Latency control - набір архітектурних і протокольних технік, що утримують затримку в заданих SLO при піках, втраті пакетів і деградаціях залежностей.

Ключові ідеї: локальність, асинхронність, деградація з пріоритетом цінності.

2) Карта периметра

Static/Assets CDN: кешування, image/HTML-transform, Brotli, WebP/AVIF, HTTP/3.
Edge compute: функції/воркери (Cloudflare Workers, Fastly Compute @Edge, Vercel Edge, Fly. io).
Edge data: KV/SQLite-на-edge/Durable Objects/Global Tables (із застереженнями щодо консистентності).
Edge security: WAF/Rate limit/Bot mgmt/Geo-rules/HMAC перевірки.
Edge networking: Anycast, smart-routing, TCP/QUIC оптимізації.

3) Патерни розміщення логіки

Shielding & warmup: origin-shield шар, прогрів/пінінг популярних ключів.
Compute-on-read: персоналізація банерів, A/B-розгалуження, geo-редиректи.
Pre-auth at edge: валідація JWT/HMAC, відкидання «сміття» до ядра.
Write-through queue: запис користувацьких подій в edge-чергу з асинхронною доставкою в ядро (ідемпотентність!).
Feature flags @ edge: швидкі перемикачі деградації (режим «полегшеної» сторінки/каталогу).

4) Протоколи і транспорт

HTTP/3 (QUIC): менший handshake-оверхаїд, стійкість до втрати пакетів. Вмикайте 0-RTT тільки для ідемпотентних GET/HEAD.
TCP tuning (для HTTP/1. 1/2): BBR/CUBIC, `tcp_fastopen`, `keepalive`, connection pooling.
TLS: OCSP stapling, ECDSA-серты, session resumption; HSTS на периметрі.
DNS: короткі TTL (30-120с) для динаміки, split-horizon, anycast-резолвери.

5) Управління «хвостами»: p95/p99

Hedged requests: дублюйте запит на другий бекенд після «стартового дедлайну» (наприклад, p90 латентності) і скасовуйте переможеного.
Deadline propagation: передавайте'x-deadline-ms '/' grpc-timeout', щоб ланцюжок не перевищував SLA.
Adaptive concurrency: обмежуйте паралелізм на роут/тенант по observed-latency (AIMD).
Bulkhead & priority: критичні шляхи (логін/депозит) отримують квоту і чергу вище класу.

6) Таймаути, ретраї та ідемпотентність

Total deadline < per-hop timeout × N; ретраї тільки для ідемпотентних операцій.
Backoff + jitter (напіввипадкові затримки), hedging замість сліпих ретраїв.
Idempotency-Key для POST-ів (гаманці/платежі/бонуси).
Retry-After і клієнтські підказки (429/503) з експоненціальним вікнами.

Envoy (фрагмент маршруту)

yaml route:
timeout: 300ms retry_policy:
retry_on: "reset,5xx,connect-failure"
num_retries: 1 per_try_timeout: 150ms retry_host_predicate:
- name: envoy. retry_host_predicates. previous_hosts host_selection_retry_max_attempts: 3 hedge_policy:
initial_requests: 1 additional_request_chance: { default_value: 0. 5} # enable after per-timeout

7) Кешування і консистентність

Cache key дисципліна: нормалізація заголовків/квері, Vary по потрібних полях.
Stale-while-revalidate: миттєва віддача «трохи застарілого» + фонова актуалізація.
Soft TTL/Hard TTL: м'яке застарівання для read-шляхів, жорсткі TTL для критичних конфігурацій.
Signed exchanges / Signed URLs: захист гарячих ресурсів, у тому числі регіональні обмеження.

NGINX (SWR приклад)

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale updating error timeout http_500 http_502 http_504;
add_header Age $upstream_cache_status;

8) Edge-workers: приклади

Cloudflare Workers (JWT + Geo)

js export default {
async fetch(req, env, ctx) {
const url = new URL(req. url);
const { country } = req. cf          {};
//Simple geo-policy if (country & &! ["DE, ""PL, ""SE,"" UA"] .includes (country)) {
return new Response("Region not served", { status: 451 });
}
//Easy JWT validation const token = req. headers. get("Authorization")?.replace("Bearer ","");
if (!token! isValid(token, env. JWTPUB)) return new Response("",{status:401});
//Prefetch critical data const resp = await fetch ("https ://origin. internal/api/v1/catalog", { cf:{ cacheTtl: 60, cacheEverything: true }});
return new Response(resp. body, resp);
}
}

Fastly Compute @Edge (канареїка за вагою)

У вітальнях/сторінках - 5% на нову версію, швидкий відкат через edge-конфіг.

9) Пріоритизація і деградація

Priority hints: HTTP/2 пріоритети/НТТР Early Hints (103) → ранній push критичних ресурсів.
Degrade path: спрощений темплейт UI, відключення важких віджетів, зниження якості зображень.
Traffic shaping: обмеження анімацій, віджетів сторонніх провайдерів при поганій мережі (RUM-сигнали).

10) Спостережуваність на периметрі

RUM + Synthetic: Web-Vitals (LCP/CLS/INP), TTFB, RTT, втрати QUIC.
Exemplars: зв'язуйте p99 спайки з конкретними trace_id і PoP.
SLO на регіон/ASN/провайдера: «p95 TTFB ≤ 200 мс», «p99 API ≤ 400 мс».
Tail-sampling: зберігати помилки/р99, сегментами'edge _ pop','region','tenant'.
Edge logs: WAF hits, bot-score, cache-status, гео-рішення.

11) Управління сторонніми скриптами

Політика CSP і Subresource Integrity.
Завантаження по defer/async, ізольовані домени, критичні шляхи - без блокуючих сторонніх JS.
Персоналізація і трекінг - виконувати на edge асинхронно, без впливу на TTFB.

12) Антибот/антифрод на edge

Device fingerprint і velocity-ліміти до ядра.
Token binding (одноразові токени на форму/операцію), HMAC підпис запиту.
Challenge-step (Turnstile/hCaptcha) тільки при підвищеному ризику; кешувати «довіру» за IP/ASN/сеансом.

13) Специфіка iGaming/фінансів

Geo-compliance: блокування/перенаправлення за юрисдикцією на edge (сторінки правил, Responsible Gaming).
PSP/KYC пріоритизація: edge-маршрутизація на «здорового» провайдера (smart-routing), окремі TTL/ваги на DNS для PSP доменів.
Anti-abuse: ліміти по депозиціях/реєстраціях/бонусах з урахуванням velocity-сигналів на edge; всі write-операції - ідемпотентні.
Data residency: персональні дані не кешуються на edge; PII-заголовки редагуються/видаляються, включена TLS-пінning до PSP.
CLO для «грошових» шляхів: більш строгі p95/p99, виділені квоти, окремі алерти.

14) Архітектурні рецепти

14. 1 «Швидкий фронт»

HTML-шаблон і критичний CSS на edge, дані - через'stale-while-revalidate', heavy-віджети - ліниво.

14. 2 «Шлях грошей»

Pre-auth + HMAC на edge, швидкі перевірки правил/лімітів, публікація в чергу, відповідь 202/OK, наступний вебхук/полінг; дедлайни і hedging до PSP.

14. 3 «Каталоги/ігри»

Каталоги/конфіги - глобальні KV/edge-кеш; для регіональної ціни/віку - compute-на-edge з локальними правилами.

15) Продуктивність і вартість

Кеш-хіт ≥ 95% для статики і ≥ 70% для напів-динаміки (HTML-фрагменти) - цільовий орієнтир.
Знижуйте «крос-регіональний egress» через локальні PoP і stale-відповіді.
Tail-rules трейсингу обмежують обсяг × 10- × 100 при збереженні цінних кейсів.
Протокол QUIC економить RTT, але тримайте fallback на H2.

16) Чек-лист prod-готовності

• HTTP/3/QUIC включений; 0-RTT тільки для ідемпотентних.
• Edge-workers: JWT/HMAC валідація, geo-правила, feature-flags деградації.
• Кеш-стратегія: ключі, SWR, soft/hard TTL; origin-shield + прогрів.
• Hedging, deadline-propagation, адаптивний concurrency, bulkheads.
• Таймаути/ретраї: backoff + джиттер, тільки ідемпотентні повторення.
• RUM+synthetic; SLO по регіону/ASN; tail-sampling р99/помилок.
• CSP/SRI і контроль сторонніх скриптів; WAF/bot-скоринг на edge.
• Для iGaming: geo-compliance, smart-routing PSP, ідемпотентність write, відсутність PII в кеші.
• Runbooks: як включити деградацію/перемкнути вагу/відкотити канарію.
• Тести: латентність під втратою 1-3%, хаос-затримки, rehearse-фейловер DNS.

17) TL; DR

Доставте логіку якомога ближче до користувача (edge-workers + кеш), говоріть по HTTP/3/QUIC, жорстко контролюйте таймаути/дедлайни, «стрижте хвости» p99 hedging'ом і bulkhead/priority. Критичні шляхи - окремі квоти і SLO, всі записи - ідемпотентні. Спостережуваність - RUM + synthetic + tail-tracing. Для iGaming - geo-комплаєнс, smart-routing PSP/KYC, нульовий витік PII на периметрі і швидкі режими деградації.