System Design Case Studies

The best way to internalise system design principles is to apply them. This lesson walks through four real-world system designs: a URL shortener, a chat system, a news feed, and a notification service. Each follows the framework: requirements, estimation, high-level design, component breakdown, and trade-offs.

---

Case Study 1: URL Shortener

Requirements

Functional:

• Given a long URL, return a short URL (e.g. short.ly/abc123)
• When a short URL is accessed, redirect to the original URL
• Custom short links (optional)
• Link expiration

Non-Functional:

• 100M new URLs per day
• 10:1 read-to-write ratio (1B redirects per day)
• Short URLs should be as short as possible
• Low latency (< 50ms for redirection)
• High availability (cannot go down)

Back-of-the-Envelope

$$\begin{aligned} \text{Write QPS} &= 100\text{M} / 86{,}400 \approx 1{,}160 \text{ writes/sec} \\ \text{Read QPS} &= 1\text{B} / 86{,}400 \approx 11{,}600 \text{ reads/sec} \\[4pt] \text{Storage per URL} &\approx 500 \text{ bytes (short URL + long URL + metadata)} \\ \text{Daily storage} &= 100\text{M} \times 500 = 50 \text{ GB/day} \\ \text{5-year storage} &= 50 \times 365 \times 5 \approx 91 \text{ TB} \end{aligned}$$Write QPSRead QPSStorage per URLDaily storage5-year storage​=100M/86,400≈1,160 writes/sec=1B/86,400≈11,600 reads/sec≈500 bytes (short URL + long URL + metadata)=100M×500=50 GB/day=50×365×5≈91 TB​

High-Level Architecture

graph LR
  Client["Client"] --> LB["Load Balancer"]
  LB --> App["App Servers"]
  App --> Cache["Cache (Redis)"]
  App --> DB["Database (NoSQL)"]
  App --> ID["ID Generator"]

Short URL Generation

Use Base62 encoding (a-z, A-Z, 0-9) with a 7-character key:

With a 7-character code, base-62 (using a–z, A–Z and 0–9) gives 62⁷ ≈ 3.5 trillion possible URLs — enough for years. The numeric ID is simply encoded into that base: for example, 1234567 becomes "5BAN".

ID Generation options:

• Auto-incrementing DB ID
• Distributed ID generator (Snowflake)
• Hash + collision check (MD5/SHA → take first 7 chars)

Trade-offs

Decision	Trade-off
NoSQL over SQL	Better horizontal scaling, but no native joins
Cache-heavy	Fast reads, but cache invalidation complexity
Base62 over hash	Shorter URLs, but needs unique ID generation
Eventual consistency	Higher availability, but stale reads possible

---

Case Study 2: Chat System (e.g. WhatsApp/Slack)

Requirements

Functional:

• 1-on-1 messaging
• Group chats (up to 500 members)
• Online/offline status
• Message delivery confirmation (sent, delivered, read)
• Message history

Non-Functional:

• 50M daily active users
• Average 40 messages/day per user
• Low latency (< 200ms for message delivery)
• Messages must not be lost
• Support for media (images, files)

High-Level Architecture

graph TD
  CA["Client A"] ==>|"WebSocket"| CS["Chat Server (stateful WebSocket connection)"]
  CB["Client B"] ==>|"WebSocket"| CS
  CS --> MQ["Message Queue (Kafka)"]
  CS --> PR["Presence Service (Redis)"]
  CS --> MS["Media Storage (S3)"]
  MQ --> MDB["Message Database (Cassandra)"]

Message Flow

graph TD
  S1["1. Client A sends message via WebSocket"] --> S2["2. Chat server receives message"]
  S2 --> S3["3. Message published to Kafka"]
  S3 --> S4["4. Message persisted to Cassandra"]
  S4 --> S5["5. If Client B online: push via WebSocket"]
  S4 --> S6["6. If Client B offline: store for later delivery"]
  S5 --> S7["7. Delivery confirmation sent back to Client A"]

Key Design Decisions

Component	Choice	Reasoning
Connection	WebSocket	Bidirectional, low latency
Message store	Cassandra	Write-heavy, partitioned by chat_id
Message queue	Kafka	Ordered delivery, replay capability
Presence	Redis	Fast reads/writes, TTL for timeout
Media	S3 + CDN	Scalable blob storage

---

Case Study 3: News Feed (e.g. Twitter/Facebook)

Requirements