Classic System Design Problems

These five problems appear repeatedly in interviews. Knowing their solutions builds the muscle memory to tackle any design problem.

1. URL Shortener (Like bit.ly)

Requirements: Generate short URLs, redirect to original, handle high read traffic.

Key Design Decisions:

Component	Choice	Why
ID Generation	Base62 encoding (a-z, A-Z, 0-9)	62^7 = 3.5 trillion unique codes
Database	NoSQL (DynamoDB)	Simple key-value lookups, high throughput
Cache	Redis	80/20 rule: 20% of URLs get 80% of traffic
Architecture	Read-heavy	100:1 read-to-write ratio

Flow:

Create: Client → API → Generate ID → Store in DB → Return short URL
Redirect: Client → CDN/Cache → DB (on miss) → 301 Redirect

2. Rate Limiter

Requirements: Limit API requests per user/IP to prevent abuse.

Algorithms:

Algorithm	How It Works	Pros	Cons
Token Bucket	Tokens added at fixed rate, each request consumes a token	Allows bursts, smooth	Needs tuning
Sliding Window Log	Track timestamps of requests in a window	Accurate	Memory-heavy
Sliding Window Counter	Combine fixed window counts with sliding calculation	Low memory, accurate enough	Approximate
Fixed Window	Count requests in fixed time windows	Simple	Boundary burst problem

Where to place it: API Gateway or as middleware. Use Redis for distributed rate limiting across multiple servers.

3. Chat System (Like WhatsApp/Slack)

Requirements: 1:1 messaging, group chats, online presence, message history.

Key Components:

Clients ↔ WebSocket Servers ↔ Message Queue (Kafka)
                                    ↓
                              Message Store
                              (Cassandra)

Decision	Choice	Why
Protocol	WebSocket	Bidirectional, real-time, persistent connection
Message storage	Cassandra	Write-heavy, time-series data, partition by chat_id
Message delivery	Push (WebSocket) + Pull (on reconnect)	Reliable delivery
Online presence	Redis with TTL	Fast lookups, auto-expire
Group messages	Fan-out on write (small groups) or fan-out on read (large groups)	Trade-off: write amplification vs read latency

4. News Feed (Like Twitter/Facebook)

Requirements: Users post content, followers see posts in chronological/ranked order.

Two approaches:

Approach	How	Pros	Cons
Fan-out on write	When user posts, push to all followers' feeds	Fast reads	Slow writes for celebrities (millions of followers)
Fan-out on read	When user opens feed, pull from followed users	Fast writes	Slow reads, needs merging
Hybrid	Fan-out on write for normal users, on read for celebrities	Balanced	More complex

Architecture:

Post Service → Fan-out Service → Feed Cache (Redis)
                                      ↓
                                Feed Service → Client

5. Notification Service

Requirements: Send push/email/SMS notifications reliably at scale.

Design:

Trigger Event → Notification Service → Priority Queue
                                            ↓
                                    ┌───────┼───────┐
                                    ↓       ↓       ↓
                                  Push    Email    SMS
                                (APNs/   (SES)  (Twilio)
                                 FCM)

Key considerations:

Deduplication: Idempotency keys to prevent duplicate notifications
Rate limiting: Don't overwhelm users
Priority: Urgent notifications bypass queue
Retry: Exponential backoff with dead-letter queue for failures
Templates: Centralized template management for consistency

System Design Answer Template

When you walk through any design, follow this structure:

"The system needs to..." (requirements)
"At this scale, that means..." (estimation)
"The high-level architecture is..." (diagram)
"For [component], I'd choose [X] because..." (justified decisions)
"The trade-off here is..." (shows maturity)
"To handle [edge case], we'd..." (demonstrates depth)

Next, let's cover scaling patterns and reliability -- the topics that differentiate senior candidates. :::