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 приоритеты/HTTP 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: сохранять ошибки/p99, сегментами `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.
СLO для «денежных» путей: более строгие 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 p99/ошибок.
• 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 на периметре и быстрые режимы деградации.