Шпаргалка: проєктування систем

Затримка vs пропускна здатність

Затримка — час одного запиту (p50, p99). Пропускна здатність — скільки запитів/сек система тримає. Високий пропускна здатність не гарантує низький p99.

Little's Law: середня кількість у системі = arrival частота × середній час. Черга росте, коли навантаження наближається до capacity.

Доступність (nines)

Частка часу безвідмовної роботи за рік. Кожна «девʼятка» — на порядок менше простою.

SLI, SLO, SLA

SLI — вимір (затримка p99). SLO — ціль (p99 < 200 ms). SLA — контракт з наслідками (кредити), якщо SLO порушено.

Horizontal vs vertical scale

Vertical — більший CPU/RAM на одній машині (стеля). Horizontal — більше вузлів + балансувальник навантаження (складніше, але далі масштабується).

CAP (спрощено)

При network розділ (P) розподілена система обирає між Узгодженість (усі бачать одне) і Доступність (кожен запит відповідає). На практиці — спектр моделей, не binary C vs A.

Сувора vs кінцева узгодженість

Сувора — читання бачить останній запис (linearizable). Кінцева — репліки зійдуться з часом; нижча затримка, вища пропускна здатність запису.

Read-your-writes, causal — проміжні гарантії для UX без повної суворої узгодженості.

ACID vs BASE

ACID — транзакції SQL (Atomicity, Узгодженість, Isolation, Durability). BASE — Basically Available, Soft state, кінцева узгодженість — типово NoSQL під навантаженням.

Ідемпотентність

Повторний запит дає той самий ефект — критично для повтори, черги, payment. Ідемпотентність ключ у API.

QPS і сховище

DAU × actions/day ÷ 86400 ≈ avg QPS; peak ≈ 2–10× avg. Сховище = records × size × зберігання × реплікація factor.

Затримка budget

Розкладіть p99 end-to-end: DNS, TLS, LB, app, DB, кеш. Якщо sum(parts) > SLO — оптимізуйте найповільніший hop.

1 ms same-DC RTT; cross-region — десятки–сотні ms. Serial calls додаються; parallel — max.

Пропускна здатність диска/мережі

SSD ~ сотні MB/s–GB/s; HDD ~ сотні MB/s sequential. 1 Gbps ≈ 125 MB/s теоретично. Вузьке місце часто DB або N+1 queries, не «CPU на папері».

DNS у архітектурі

Резолв імені → IP; TTL кешує зміни. Geo DNS / weighted routing — трафік на регіони. Health checks оновлюють записи.

Балансувальник навантаження

Розподіл трафіку між instances: round-robin, least connections, consistent хеш (sticky по ключ). L4 (TCP) vs L7 (HTTP path/host).

Active перевірки здоровʼя; drain node перед розгортанням. Сесія stickiness — cookie або хеш, компроміс з відмовою з перемиканням (failover).

CDN

Край кешує static (JS, images, video). Користувач ближче до PoP — нижча затримка. Походження — ваш сервер при промах кешу.

Кеш-Control, ETag; інвалідація через purge API або короткий TTL для dynamic-ish content.

Reverse proxy

Nginx/Envoy перед app: TLS termination, обмеження частоти, routing, compression — один вхід для клієнта.

SQL vs NoSQL (коли що)

SQL — joins, транзакції, чітка схема (orders + користувачі). NoSQL — document/KV/wide-column/graph під massive scale, flexible schema, простіший доступ патерн.

Реплікація

Лідер-послідовник: writes на лідер, reads з репліки (lag!). Multi-лідер — конфлікти; leaderless — quorum читання/запис (Dynamo-style).

Синхронна реплікація — сильніша durability, вища затримка запису. Асинхронна — швидше, ризик втрати останніх writes при failover.

Шардування (partitioning)

Горизонтальний поділ даних: хеш(user_id) mod N, range (user_id 0–1M), geo. Rebalance при додаванні шард — consistent hashing зменшує переміщення.

Cross-шард joins/transactions — дорогі; проектуйте доступ патерн навколо шард ключ.

Індекс і N+1

Індекс прискорює читання, сповільнює запис. N+1 — цикл запитів замість одного join/batch; типова причина повільного API.

Кеш-aside

App: читання кеш → промах → DB → запис кеш. Простий патерн; app відповідає за узгодженість з DB.

TTL — автоматичне застаріння. Кеш stampede — багато промах одночасно; рішення: singleflight, jitter TTL.

Write-through / відкладений запис

Write-through — запис у кеш і DB разом (узгодженість). Write-back — спочатку кеш, асинхронний flush (швидше, ризик втрати).

Invalidation

Delete/update кеш при зміні DB — інакше stale reads. Version ключ у кеш entry; pub/sub для multi-instance інвалідація.

Redis use cases

In-memory: сесія, обмеження частоти, leaderboard, pub/sub, розподілений lock (обережно з TTL і fencing token). Не заміна primary DB без persistence план.

Повідомлення черга

Decouple producer/consumer: spikes поглинає черга, воркер обробляє в своєму темпі. At-least-once delivery — consumer ідемпотентний.

Kafka — log, replay, high пропускна здатність; RabbitMQ/SQS — classic черга; dead-letter черга для failed повідомлення.

Зворотний тиск (backpressure)

Коли consumer повільний — не завалювати памʼять; блок/slow producer, max розмір черги, 429 на API.

Асинхронний робочий процес

HTTP 202 + задача id + опитування/webhook для довгих задач (video encode, export). Клієnt не тримає connection хвилини.

Event-driven

Події (order.created) → кілька subscribers: email, analytics, inventory. Loose coupling; потрібна ordering гарантія лише де треба.

Резервування і радіус ураження

N+1, multi-AZ, multi-region — failure одного вузла не валить сервіс. Blast radius — скільки користувачів/функцій зачепить один incident.

Timeouts, повтори, автоматичний вимикач

Timeout — не чекати вічно. Retry з exponential backoff + jitter на transient errors. Circuit breaker — при серії fail швидко fail open, дати upstream відновитись.

Retry лише для ідемпотентних ops або з ключем ідемпотентності; інакше дубльовані побічні ефекти.

Graceful degradation

Вимкнути recommendations, лишити checkout. Прапорці функцій; static fallback коли dependency down.

Disaster recovery

RPO — скільки даних можна втратити (backup interval). RTO — скільки часу на відновлення. Regular restore drills, не лише backup.