System Design: real interview questions

Clarify scale first (reads dominate ~100:1). Cover: ID generation (base62 counter vs hash), storage schema, redirect latency (cache), and analytics as an async concern.

Requirements: shorten URLs, redirect fast, ~100M new/month, reads 100x writes. Core: a key-generation service — I'd use base62-encoded IDs from partitioned counters (no collision checks needed, 7 chars covers trillions) — and a key→URL table (key-value store; DynamoDB or sharded MySQL both fine). Redirects: check a cache first (Redis, ~90%+ hit rate for hot links), fall back to the store; serve a 301 (or 302 if we want analytics on every hit). Analytics: publish click events to a queue, aggregate asynchronously — never in the redirect path. Add rate limiting on creation, TTL/archival for dead links, and replicate the read path across regions since redirect latency is the product.

Compare algorithms (fixed window, sliding window, token bucket), then make it distributed: where state lives, race handling, and fail-open vs fail-closed.

I'd use token bucket per API key: capacity = burst allowance, refill rate = sustained limit — it allows natural bursts while capping throughput. Single node it's trivial; distributed, the state goes in Redis with a Lua script so read-refill-decrement is atomic. To cut Redis load, give each gateway node a small local allowance synced periodically (slight over-admission tolerated). Return 429 with Retry-After and rate-limit headers so clients back off politely. Two judgment calls: fail-open if Redis dies (availability over strictness — usually right for product APIs, wrong for payments), and tiered limits (per-key, per-IP, global) so one abuser can't starve the platform.

The heart is fan-out on write (push to followers' feeds) vs fan-out on read (pull at request time) and the celebrity-user hybrid. Then ranking and pagination.

Write path: user posts → store post → fan out post IDs to followers' feed lists (Redis) via async workers. That makes reads O(1): fetch precomputed ID list, hydrate posts, rank, return. The problem is celebrities — fanning out to 50M followers per post is wasteful, so hybrid: normal users push; celebrity posts are pulled and merged at read time from a small 'following-celebrities' set. Rank with a lightweight scorer (recency, affinity, engagement) at read. Paginate with cursors, not offsets. Cache hydrated posts hard — the same hot posts appear in millions of feeds. Consistency is eventual and that's fine; nobody notices a feed item arriving three seconds late.

They're testing how deep you can go and where you choose to zoom. Hit the checkpoints (DNS, TCP/TLS, HTTP, server, render) and go deep where the role cares.

Browser checks its caches, then DNS resolves the name (recursive resolver → root → TLD → authoritative, cached at each hop). TCP handshake to the IP (SYN/SYN-ACK/ACK), then TLS (ClientHello, cert verification against trusted CAs, key exchange). The HTTP request goes out; typically hits a CDN edge — cache hit serves immediately, miss forwards to a load balancer, then an app server, which may call services/databases and returns HTML. Browser parses HTML, discovers CSS/JS/images, fetches them in parallel, builds DOM + CSSOM, runs JS, lays out, paints. For this role I'd zoom into [the layer relevant to the job] — say the word and I'll go three levels deeper there.

Key decisions: connection layer (WebSockets), message flow and ordering, delivery guarantees (ack + retry + dedup), presence, and offline delivery.

Clients hold WebSocket connections to gateway servers; a connection registry (Redis) maps user → gateway. Send flow: sender → gateway → chat service persists to storage (write-ahead, e.g. Cassandra keyed by conversation, time-ordered) → push to recipient's gateway if online, else queue for delivery on reconnect + mobile push notification. Guarantees: at-least-once with per-message IDs, client dedup, and per-conversation sequence numbers for ordering — 'exactly-once' is achieved by retry + idempotent receive, not magic. Presence via heartbeats with a grace window. Group chat: fan out server-side, but for very large channels deliver on read like a feed. End-to-end encryption changes storage (server stores ciphertext) — worth calling out as a fork in the design.

Cover partitioning (consistent hashing), replication, eviction (LRU variants), invalidation strategy, and the classic failure modes: hot keys, thundering herd, stale data.

Partition the keyspace with consistent hashing (virtual nodes for even spread) so adding/removing nodes remaps only a fraction of keys. Each shard: in-memory store with LRU (or TinyLFU for scan resistance), optional async replication to one replica for availability. Clients (or a proxy tier) route by hash. Invalidation: TTLs as the safety net plus explicit deletes on write. Failure modes I'd design for explicitly: thundering herd (single-flight — one loader per key, others wait), hot keys (local L1 cache on clients + key replication), and cascading refill after a node loss (warm-up throttling). Metrics that matter: hit rate, p99 latency, evictions — a cache without hit-rate monitoring is a rumor, not a system.