System Design Cases

Классический системный собес — спроектировать TinyURL/bit.ly. Разбираем стратегии генерации ID, cache-aside паттерн, узкие места при масштабировании. Пилотный кейс нового /cases формата.

Классический system design — спроектировать rate limiter для защиты API. Token bucket, Redis-backed, atomic Lua. Пилот #2 нового /cases формата.

Full Instagram architecture: post upload, feed generation (fan-out on write), social graph, engagement. Covers pre-signed URLs, cache-aside, CQRS, event-driven patterns.

Системный дизайн ленты Twitter/X. Snowflake IDs, гибридный fanout (write для обычных пользователей, read для celebrities), Redis hot timeline + Cassandra durable. Кейс уровня senior-собеса.

Distributed web crawler at billion-page scale: BFS frontier, per-host politeness, Bloom-filter dedup, async fetcher pool, S3 + Kafka storage tier.

Real-time chat at 100M concurrent users: WebSocket fleet, sticky routing via consistent hash, per-chat sharded message DB, Kafka fan-out for groups, APNS/FCM push for offline.

Ride-hailing at 100M users / 1M concurrent drivers: 200K location pings/sec, geohash-sharded Redis GEO, 5km-radius matching, surge pricing, trip lifecycle.

Pastebin system design case study. Client posts text snippets via HTTPS through a CDN and Load Balancer to the paste-svc. paste-svc generates a base62 short ID (8 chars), stores the body in S3 under sharded prefixes, and persists metadata (lang, ttl, s3_key, visibility) in Postgres. Hot pastes are cached in Redis. Reads are served via CDN for /raw views and rendered HTML pages bypass the CDN to keep view counts accurate. A TTL cleanup cron sweeps expired pastes from S3, Postgres and Redis. ADRs: KV store choice (S3 + Postgres metadata), ID generation strategy (base62 hash with collision retry), CDN caching for raw views. Capacity: 10M DAU, 1M new pastes/day, 10:1 read:write, viral pastes 100x burst. Six scenarios: create paste, view with cache miss, raw CDN hit, viral burst absorbed by CDN+Redis, TTL cron cleanup, abuse rate limiting.

Multi-channel notification system (push, email, SMS, in-app) handling 100M DAU with 5.8K rps avg / 50K rps peak. Producers publish events to Kafka, orchestrator loads user preferences, dedups via Redis, renders templates, then dispatches to per-channel queues (q-push, q-email, q-sms). Channel workers (push/email/sms) post to APNs/FCM/SES/Twilio with retry-backoff and DLQ. Provider webhooks update ClickHouse for delivery status analytics.

News Feed (Twitter/Instagram timeline) system design case. Hybrid push/pull fan-out with celebrity-tier carve-out, per-user Redis ZSET inbox cache, ML ranking pipeline. 5 scenarios cover regular post fanout-on-write, celebrity post skip-push, feed-view cache hit + ranking, cache-miss rebuild from Cassandra, and ranking pipeline reordering. 2 ADRs: push-vs-pull-vs-hybrid trade-off and capped-ZSET + idle-TTL eviction. Capacity hints on every node.

CDN system design case: client → DNS (anycast) → edge PoP (cache + WAF + Worker) → tiered cache (regional + origin shield) → customer origin, with global control plane (config, purge, logs). 5 scenarios: edge cache hit, tiered miss fetch, global purge fan-out, DDoS absorption, video chunked streaming. 2 ADRs: anycast vs GeoDNS, push vs pull CDN. Capacity hints on every node.

Social Graph (LinkedIn / Facebook TAO) — 1B users, 200B+ edges. Sharded MySQL adjacency (objects+assoc tables, sharded by id1) behind a stateless TAO-style cache tier (Memcached, 99% hit). Two ADRs: graph DB vs sharded SQL adjacency, and cache strategy for hot edges (celebrities). 5 scenarios: add friend (bidirectional write + invalidate), friends-of-friends 2-hop (scatter-gather), mutual friends (sorted-list intersection), PYMK (2-hop + ML rerank via PyTorch BigGraph), hot celebrity read (pre-sharded follower list with leases).

Web-scale search engine (Google-like). Crawler -> URL frontier (Kafka) -> fetcher -> parser -> bulk indexer -> sharded inverted Lucene index (150 shards × RF 3). Query path: API gateway -> query cache -> spell corrector -> query rewriter -> coordinator (scatter-gather) -> shards (BM25) -> PageRank static scores -> ML re-ranker (LambdaMART). Auto-suggest service backed by in-RAM prefix trie. Semantic search via embedding model + HNSW vector index, fused with BM25 via Reciprocal Rank Fusion. Five scenarios: crawl-and-index a new page, search query (BM25 + ML rerank), auto-suggest while typing, spell correction "googel" -> "google", hybrid vector + lexical retrieval. Two ADRs: inverted index sharding strategy (document-partitioning vs term-partitioning), BM25 vs vector vs hybrid retrieval.

Distributed Message Queue (Kafka-style) case study. Producers (idempotent + transactional) write batched/compressed records to a 3-broker cluster (DC-1) with RF=3 and min.insync.replicas=2. Three partitions (P0/P1/P2) each have a leader and 2 followers spread across racks. Control plane is KRaft metadata quorum (no ZooKeeper) with 3 voters, plus group coordinator and transaction coordinator. Two consumer groups: analytics (auto.commit=false, 1:1 partition assignment) and alerting (read_committed for EOS). Internal compacted topics: __consumer_offsets, __transaction_state, __cluster_metadata. Multi-DC mirror via MirrorMaker 2 to DC-2, with tiered storage (S3) for cold segments. Two ADR panels: pull vs push consumer model, KRaft vs ZooKeeper metadata. Six animated scenarios: produce + ISR replicate (acks=all), consumer group fetch + offset commit (zero-copy sendfile), leader broker failure + ISR election (KRaft fast failover), replay from offset (retention + tiered recovery), exactly-once via transactional producer (PID/epoch fence + 2PC commit markers + read_committed), and ADR walkthrough.

Distributed Key-Value Store (Dynamo/Cassandra-style) with consistent hash ring (RF=3, W=2, R=2 quorum), vector-clock conflict resolution, hinted handoff, anti-entropy via Merkle trees, and read repair. Includes 5 scenarios: PUT quorum, GET with read repair, partition + hinted handoff, Merkle anti-entropy, concurrent-write conflict resolution.

Object Storage (S3-like) — system design case showing buckets, immutable objects, PUT/GET/DELETE, multipart upload, erasure coding 12+4 for 11-nines durability, metadata vs data plane separation, tiered storage (Standard/IA/Glacier), versioning, lifecycle policies. 5 scenarios: PUT with EC, multi-region GET, multipart upload, lifecycle migration to Glacier, tail latency at scale. 2 ADRs on metadata/data plane split and EC vs replication.

Video Hosting (YouTube-like) — TUS resumable upload, FFmpeg/GPU transcoding pool with CMAF/HLS multi-bitrate ladder, Kafka job queue, S3 raw + variants, mid-tier + edge CDN PoPs, ABR player with quality switching, view counter via Redis HLL, Cassandra watch history, Postgres meta, Elasticsearch search, recsys, plus live streaming RTMP -> LL-HLS pipeline. Five scenarios: upload+transcode, playback ABR with quality downshift, viral CDN cache hit, view counter at scale, live streaming with packet loss recovery. ADR-001: pre-transcode vs JIT. ADR-002: HLS vs DASH vs CMAF.

Stripe-style payment system case: API gateway with WAF and Redis idempotency cache, payment core with charge service, saga orchestrator, HSM tokenization, Postgres double-entry ledger and outbox, external Visa/Mastercard/SEPA rails via processor adapter, async fan-out via Kafka to webhook dispatcher, reconciliation cron, and payouts. Five animated scenarios: happy-path card charge with idempotency key, retry duplicate caught at idempotency layer, refund with compensating ledger entry, subscription rebill via cron with saved token, and nightly reconciliation cron catching webhook-lost mismatches. Two ADRs: idempotency-key dual-storage strategy (Redis fast path + Postgres unique-index backstop) and ledger storage choice (Postgres double-entry with outbox vs append-only event store). Capacity hints throughout.

Hotel Booking (Booking.com style) — system design case. Search → Booking Saga (hold → pay → confirm) → Payment → Notifications. Demonstrates no-double-booking via hybrid pessimistic-lock-on-hold + saga compensation, Elasticsearch search vs Postgres FTS trade-offs, dynamic pricing, cancellation/refund flow, and concurrent reservation race resolution. Five FlowBuilder scenarios + 2 ADRs (inventory consistency, search engine choice) + capacity hints on every node.

Ticket booking system case study (Ticketmaster, BookMyShow): browse events, select seats with TTL hold, pay, confirm. Handles flash sales (1M concurrent, 100K seats). Components: CDN, WAF/CAPTCHA with ML bot scoring, virtual waiting room (Redis sorted set), API gateway, event catalog (Cassandra), Redis SETNX hold service with 10-min TTL, sharded Postgres inventory, payment service to PSP (Stripe/Adyen), seat-map WebSocket, outbox to Kafka, notifications. Five scenarios: virtual queue under flash sale, atomic seat hold conflict, checkout to PSP and PG transaction, hold TTL expiry, anti-bot scalper detection. Two ADRs: virtual waiting room vs FCFS, Redis SETNX TTL vs Postgres row-lock.

Design ad click aggregator at Google Ads / Facebook Ads scale. 1M clicks/sec sustained, near-real-time aggregation (1m lag), exact billing. Pipeline: Browser/Mobile beacons -> Edge CDN -> Click Ingest API -> Kafka (5K partitions) -> Flink (Enrich -> Dedup with RocksDB -> Fraud filter with Redis -> 1m Window Aggregator) -> Druid OLAP + S3 raw + Postgres ledger. 5 scenarios: happy click flow, dedup duplicate, fraud bot filtered, hot ad partition skew, daily billing reconciliation.

Recommendation system case study (Netflix/YouTube/Spotify class). Two-stage funnel: candidate generation via two-tower ANN over millions of items, then ranking via DLRM on top 1000, then re-rank for diversity and business rules. Includes cold start (popular + demo cohort + bandit explore), real-time signal updates via Kafka+Flink streaming, A/B testing with experiment assigner, drift detection and retrain pipeline. 5 scenarios and 2 ADRs (two-stage vs single model, real-time vs batch features).

Google Docs / Figma collaborative editor system design case. WebSocket gateway + per-doc session actor with CRDT merge, sharded op log (Spanner), snapshot service to blob storage, Redis presence, ACL, comments, version history, Kafka fan-out for hot docs. 5 scenarios: keystroke, concurrent edit at same anchor (CRDT merge), offline edit + sync, presence cursors, hot doc with snapshot + version restore. 2 ADRs: OT vs CRDT (pick CRDT), server-authoritative vs P2P CRDT (pick server-authoritative).

Real-time multiplayer game (FPS / Battle Royale) — server-authoritative game servers, UDP at 60Hz tick rate, client-side prediction + reconciliation, Agones matchmaking, Kafka anti-cheat telemetry feeding an ML detector. Five animated scenarios: matchmaking + spawn, 60Hz tick loop with AOI broadcast, client prediction + reconciliation on misprediction, UDP packet-loss interpolation + FEC, aimbot detection + HWID ban. Two ADRs (UDP custom vs WebRTC vs WebSocket; server-authoritative vs lockstep). Capacity hints on every node.

A/B Testing Platform — Optimizely/GrowthBook-class experimentation system: Client SDK with in-process bucketing, Control Plane with config CDN and SSE kill-switch, Event Ingest via Kafka+Flink, Stats engine with mSPRT sequential testing, Druid for real-time agg, Guardrail auto-stop. 5 scenarios + 2 ADRs.

Airbnb system design case — two-sided marketplace with search (Elasticsearch + LTR re-rank), booking saga with escrow capture-on-confirm, host approval flow, snapshotted cancellation policy refunds, smart pricing nightly batch, host calendar block, and host payout 24h after check-in. Includes 2 ADRs (escrow timing on Booking Saga, cancellation policy enforcement on Calendar Service) and capacity hints on every node.

Maps proximity / POI search system design (Yelp, Google Maps "nearby restaurants"): H3-indexed POI search with k-ring scan, hot-query cache, vector tile delivery, and OSRM-style routing. Includes 5 scenarios (nearby search, expand radius, hot tourist area, route A->B, POI ingest) and 2 ADRs (geohash vs H3 vs quadtree, vector vs raster tiles).

Distributed File System case study covering HDFS, GFS, and Ceph patterns: master/metadata server (NameNode HA via QJM + ZooKeeper) plus DataNode tier with rack-aware 3x replication. POSIX-like file API contrasted with object storage. Block-based storage (128MB), pipelined writes, streaming reads, append-only semantics. Five scenarios: pipelined chunk write to 3 replicas, parallel multi-block read with Master out of data path, append to existing file, DataNode failure with background re-replication, Active NameNode crash with Standby promotion via fence tokens. Includes 2 ADRs (single master vs sharded vs masterless Ceph CRUSH; 3x replication vs Reed-Solomon EC) and capacity hints for all nodes.