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

Write QPS = 100M / 86,400 ≈ 1,160 writes/sec
Read QPS  = 1B / 86,400   ≈ 11,600 reads/sec

Storage per URL ≈ 500 bytes (short URL + long URL + metadata)
Daily storage   = 100M × 500 = 50 GB/day
5-year storage  = 50 × 365 × 5 ≈ 91 TB

High-Level Architecture

┌──────────┐     ┌──────────────┐     ┌───────────────┐
│  Client  │────▶│ Load Balancer│────▶│  App Servers  │
└──────────┘     └──────────────┘     └──────┬────────┘
                                              │
                                    ┌─────────┼─────────┐
                                    │         │         │
                                    ▼         ▼         ▼
                               ┌────────┐┌────────┐┌────────┐
                               │ Cache  ││Database││  ID    │
                               │(Redis) ││(NoSQL) ││Generator│
                               └────────┘└────────┘└────────┘

Short URL Generation

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

62^7 = 3.5 trillion possible URLs (sufficient for years)

ID → Base62 conversion:
1234567 → "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

┌──────────┐    WebSocket     ┌──────────────┐
│ Client A │═════════════════▶│  Chat Server │
└──────────┘                  │  (stateful   │
                              │   WebSocket  │
┌──────────┐    WebSocket     │   connection)│
│ Client B │═════════════════▶│              │
└──────────┘                  └──────┬───────┘
                                     │
                          ┌──────────┼──────────┐
                          │          │          │
                          ▼          ▼          ▼
                    ┌──────────┐┌────────┐┌──────────┐
                    │ Message  ││Presence││ Media    │
                    │ Queue    ││Service ││ Storage  │
                    │ (Kafka)  ││(Redis) ││ (S3)    │
                    └──────┬───┘└────────┘└──────────┘
                           │
                           ▼
                    ┌──────────┐
                    │ Message  │
                    │ Database │
                    │(Cassandra)│
                    └──────────┘

Message Flow

1. Client A sends message via WebSocket
2. Chat server receives message
3. Message published to Kafka
4. Message persisted to Cassandra
5. If Client B is online → push via WebSocket
6. If Client B is offline → store for later delivery
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

Functional:

• Users create posts
• Users follow other users
• Home feed shows posts from followed users, sorted by time
• Support for likes and comments

Non-Functional:

• 500M users, 200M DAU
• Average user follows 200 people
• Feed should load in < 500ms
• Eventually consistent feed is acceptable

Feed Generation Approaches

Fan-out on Write (Push):               Fan-out on Read (Pull):