System Design Case Studies: URL Shortener, Chat, Feed

The fastest way to get good at system design is to study a few complete answers and notice the patterns that repeat. Each case below follows the same structure: requirements, scale, API, data model, design and trade-offs — compressed to what you can say in a 45-minute round.

1. Design a URL shortener (like bit.ly).

Requirements: create a short link for a long URL, redirect quickly, optional expiry and click counts. Reads far outnumber writes (100:1).

Key generation: take a unique id from a counter (or a range per server) and encode it in base62 — 7 characters give 62⁷ ≈ 3.5 trillion links. Storage: a key-value or SQL table (code → long URL). Redirect path: cache hot codes in Redis; return HTTP 301 for permanent links or 302 if you need to count every click. Analytics: push click events to a queue and aggregate asynchronously so redirects stay fast.

POST /api/links      { "url": "https://example.com/very/long/path" }  →  { "code": "aZ3kP9x" }
GET  /aZ3kP9x        →  301 Location: https://example.com/very/long/path

links(code PK, long_url, user_id, created_at, expires_at)

2. Design a chat application (like WhatsApp).

Requirements: one-to-one and group messages, online status, delivered/read ticks, history. Connections: clients keep a WebSocket to a chat server; a presence service maps user → server. Sending: the server stores the message, then routes it to the recipient's server through a pub/sub layer; offline users get a push notification and fetch messages when they reconnect. Storage: a wide-column store (such as Cassandra) partitioned by conversation and ordered by time suits huge write volumes. Ordering: per-conversation sequence numbers.

3. Design a news feed (like Instagram or LinkedIn).

Two strategies. Fan-out on write: when someone posts, push the post id into each follower's precomputed feed — fast reads, expensive for celebrities with millions of followers. Fan-out on read: build the feed when the user opens the app — cheap writes, slow reads. Real systems use a hybrid: fan out for normal users, merge celebrity posts at read time. Store feeds as lists of ids in a cache; hydrate post details in a batch; rank with a scoring service.

4. Design a notification system (email, SMS, push).

Services publish events (“order shipped”) to a queue. A notification service applies user preferences and templates, then puts jobs on per-channel queues; channel workers call providers (email, SMS, push) with retries and back-off. Track status per notification, de-duplicate with idempotency keys, respect quiet hours and rate limits, and fall back to another provider when one fails.

5. Design a rate limiter for an API.

Decide the rules (per user, per IP, per endpoint) and the algorithm — token bucket for bursts, sliding window for accuracy. Put it in the API gateway so every service benefits. Store counters in Redis with atomic operations (a Lua script or INCR with expiry) so all gateway instances share them. Return 429 with Retry-After, and fail open or closed deliberately if Redis is down.

allow(user):
    key = "rl:" + user + ":" + current_minute
    count = redis.INCR(key)
    if count == 1: redis.EXPIRE(key, 60)
    return count <= 100          # 100 requests per minute

6. How do you estimate storage and traffic quickly?

Use round numbers. A URL shortener with 100 million new links a month, about 500 bytes each, needs about 50 GB a month — 600 GB a year, easily handled by one database with replicas. 100 million links a month is about 40 writes per second; at 100:1 reads, about 4,000 reads per second, which a cache absorbs. Numbers like these justify every design choice you make.

7. How do you make a design highly available?

Remove single points of failure: several app servers across availability zones, a database with a standby replica and automatic failover, replicated caches and queues, health checks at the load balancer, and backups you have actually restored. Degrade gracefully — show cached data if a dependency is down.

8. What should you discuss in the last five minutes?

Bottlenecks and how you would find them (metrics, tracing), failure scenarios (a data centre goes down, a cache is cold), security (authentication, rate limits, encryption), cost, and what you would build first versus later. Ending with trade-offs leaves a strong final impression.