A repeatable talking skeleton for design rounds: requirements → estimation → components → trade-offs.

• Clarify functional and non-functional requirements first.
• Estimate scale: QPS, storage, cache hit ratio.
• Sketch the data flow with boxes for client, API, services, storage.
• Always close with a bottleneck and a trade-off discussion.

Walk a single-server app up to millions of users: web tier, data tier, cache, CDN, stateless services and sharding.

• Start with one server, then split the web tier and data tier so each scales independently.
• A load balancer plus master/slave replication removes the single points of failure.
• A cache tier, CDN, and a stateless web tier keep latency flat as traffic grows.
• When the data tier tops out, shard by a well-chosen key — the hash is the hot spot.

Turn vague requirements into QPS, storage and availability numbers using powers of two, latency tables and SLA nines.

• Know the units: 2^10 ~ 1 thousand, 2^20 ~ 1 million, 2^30 ~ 1 billion.
• Anchor on latency: memory ~100 ns, disk seek ~10 ms, network round trip ~150 ms.
• Nines map to downtime: 99.9% = ~8.8 h/year, 99.99% = ~52.6 min, 99.999% = ~5.3 min.
• Worked example: Twitter — ~3 500 QPS and ~55 PB of media over 5 years.

Design a rate limiter used at the API gateway.

• Token bucket vs sliding window — when each fits.
• In-memory vs Redis-backed counters.
• Distributed limiter coordination and fallbacks.

Distribute keys across nodes with minimal migration when the cluster grows or shrinks.

• Hash keys and nodes onto one ring; assign each key to the next node clockwise.
• Adding a node only moves keys in its own arc — about 1/K of the cluster.
• Powers Memcached, Dynamo, Cassandra and CDN sharding.
• Use virtual nodes to average out imbalance from few physical nodes.

A distributed Dynamo/Cassandra-style store: partition on a hash ring, replicate 3x, tune consistency with a quorum.

• Single-server tricks (compression, append-only log, caching) only take you so far.
• Partition with consistent hashing, then replicate to N=3 with sloppy quorum + hinted handoff.
• Vector clocks detect conflicting versions; Merkle trees reconcile replicas with minimal transfer.
• Writes go commit log -> memtable -> SSTable; reads use a Bloom filter to skip tables.

Generate unique, numeric, 64-bit, time-ordered IDs at 10 000+ per second without a central auto-increment.

• Requirements: unique, numeric, 64-bit, ordered by creation time, 10 000+ IDs/sec.
• Multi-master (+k steps), UUID (128-bit) and a ticket server each fail a requirement.
• Snowflake: 1 sign + 41 timestamp + 5 datacenter + 5 machine + 12 sequence bits.
• 41-bit millisecond timestamp earns ~69 years from a custom epoch; 4096 IDs/ms per machine.

Design a service that turns long URLs into short keys at scale.

• Base62 encoding and collision handling.
• Read-heavy workload: cache-first reads.
• Redirects as HTTP 301 vs 302 trade-offs.

Design crawling, indexing and query serving at web scale.

• Crawler politeness and deduplication.
• Inverted index and result ranking.
• Query rewrite, synonyms and typo tolerance.

Push, SMS and email at 10M+ sends a day — decoupled per channel, durable, retried and respectful of user settings.

• iOS push goes through APNs, Android through FCM; SMS and email use third-party providers.
• One message queue per channel: an outage in one provider never blocks the others.
• Persist every event, dedupe by event ID, and retry failures — at-least-once beats data loss.
• Check opt-in settings, use templates, rate-limit per user and watch queue depth.

Design the timeline behind a social product.

• Pull vs push (fan-out) delivery models.
• Ranking pipeline and pre-computation.
• Sharding user data and timeline caches.

Design a messaging system with presence, delivery and read receipts.

• WebSocket vs long-polling for realtime transport.
• Message ordering and idempotent delivery.
• Presence service and last-seen semantics.

Return the top-5 most searched queries for a prefix in under 100 ms using a cached trie rebuilt offline.

• Match only at the start of a query; return top-5 by historical frequency; no spell check.
• A trie with cached top-k per node plus a ~50-char prefix cap answers in O(1).
• Rebuild the trie weekly from aggregated logs — never update it per keystroke.
• Browser-cache results (~1 h), sample logs, and shard the trie by leading characters.

Upload and stream video at YouTube scale — 2 B users, 150 TB/day of uploads and a $150k/day CDN bill.

• 2020 reality: 2 billion MAU and 5 billion videos watched every day.
• At 5 M DAU, uploads hit ~150 TB/day and CDN egress ~$150 000/day.
• Upload: blob storage -> transcoding -> transcoded storage + completion queue -> CDN.
• Stream from the CDN (MPEG-DASH/HLS); long-tail videos serve from cheaper origin storage.

File storage and sync for 10 M DAU: 4 MB blocks, delta sync, deduplication, and long-poll notifications.

• 50 M signed-up users x 10 GB free = 500 PB of capacity; ~240 upload QPS peaking at 480.
• Files split into <= 4 MB blocks, hashed, compressed, encrypted, then chunk-synced to S3.
• Delta sync + block deduplication slash bandwidth; long polling keeps clients in sync cheaply.
• Strong consistency via ACID metadata DB — caches are invalidated on every write.

Place caches from browser to database and survive stampedes without serving stale data.

• Cache the hot read paths; stale-by-a-little is usually acceptable.
• Layers: browser headers, CDN, Redis/MemoryCache, then the database.
• Cache-aside reads with invalidate-before-write keep stale entries out.
• Beware stampedes — use single-flight in .NET to collapse concurrent misses.

Spread traffic over a server pool at every tier — DNS, CDN, L4/L7 — while staying healthy.

• DNS, anycast and CDN route at the edge; L4/L7 split inside the DC.
• Algorithms: round robin, weighted, least connections, IP/consistent hash.
• Health checks plus passive failure detection keep traffic off bad nodes.
• Load balancing forces stateless backends — sessions move to Redis.

Asynchronous messaging to decouple services, absorb traffic spikes and keep flows consistent.

• Queues decouple producer from consumer and buffer traffic spikes.
• Point-to-point delivers once; pub/sub fans out to every subscriber.
• Kafka is a partitioned, replayable log; RabbitMQ excels at routing.
• Sagas plus idempotent consumers keep cross-service flows correct.

Split a monolith at domain boundaries, front the services with a gateway, and stay resilient.

• Cut at domain boundaries; each service owns its data store.
• The API gateway centralises auth, routing, rate limiting.
• Timeout + circuit breaker wrappers prevent failure cascades.
• Observability with correlation IDs and tracing is mandatory.

Model vehicles, spots, entrance ticketing and payments.

• Enum spot types and vehicle compatibility rules.
• Ticket ↔ spot lifecycle and fare calculation.
• Where the strategy pattern removes if/else sprawl.

Domain model for catalogue, borrow/return and reservations.

• BookCopy vs BookTitle: why copies matter.
• State machine for borrow → overdue → returned.
• Hold queue management and notifications.

Model groups, expenses, shares and simplifying settlements.

• Expense with per-member share amounts.
• Compute net balances; simplify transfers greedily.
• Handle rounding so balances always sum to zero.

State-driven machine with coins, inventory and change.

• State pattern: idle, selecting, dispensing, out-of-stock.
• Coin validation, change computation and refunds.
• Inventory guards against over-dispensing.