System Design Expert¶
🧠 Soft Skills · Level 6
When you'd use this
Designing scalable systems — architecture patterns, trade-offs and interview preparation.
Reason about building systems at scale — requirements, tradeoffs, components — for design interviews and real architecture.
The system design framework¶
The system design framework — a key concept in System Design.
1. REQUIREMENTS — What exactly are we building? (functional + non-functional)
2. ESTIMATION — How much data? How many users? QPS?
3. HIGH-LEVEL — Major components and how they connect
4. DETAILED — Dive into the hardest parts
5. TRADE-OFFS — Why this design over alternatives?
Example: Design a URL shortener¶
Example: Design a URL shortener in System Design — what it is and when to use it.
Requirements¶
- Shorten a URL → return short code (7 chars)
- Redirect short code → original URL
- 100M URLs, 1000 reads/sec, 10 writes/sec
- Analytics (click count)
High-level design¶
Data model¶
# URL mapping
class URL:
short_code: str # "abc1234" (primary key)
original_url: str # "https://very-long-url.com/..."
created_at: datetime
click_count: int
user_id: int | None
Core algorithm¶
import hashlib
import string
ALPHABET = string.ascii_letters + string.digits # 62 chars
BASE = len(ALPHABET)
def encode_id(num: int) -> str:
"""Convert numeric ID to base-62 string."""
if num == 0:
return ALPHABET[0]
result = []
while num:
result.append(ALPHABET[num % BASE])
num //= BASE
return "".join(reversed(result))
def shorten(original_url: str) -> str:
# Option 1: Auto-increment ID → base62
url_id = db.insert(original_url) # returns auto-inc ID
return encode_id(url_id)
# Option 2: Hash-based
hash_hex = hashlib.md5(original_url.encode()).hexdigest()
return hash_hex[:7] # collision possible!
Scaling considerations¶
| Challenge | Solution |
|---|---|
| High read traffic | Redis cache (short_code → URL) |
| Database scaling | Sharding by short_code prefix |
| Analytics | Write to Kafka → batch aggregate |
| Availability | Multi-region deployment |
| Rate limiting | Redis-based sliding window |
Key trade-offs to discuss¶
Key trade-offs to discuss in System Design — what it is and when to use it.
| Decision | Option A | Option B |
|---|---|---|
| SQL vs NoSQL | Consistent, ACID | Scalable, flexible schema |
| Cache invalidation | TTL-based (simple) | Event-driven (consistent) |
| Sync vs Async | Simple, consistent | Higher throughput |
| Monolith vs Micro | Simple ops | Independent scaling |
| Consistency vs Availability | Strong consistency | Eventually consistent |
Common system design problems¶
Common system design problems in System Design — what it is and when to use it.
| Problem | Key challenges |
|---|---|
| URL shortener | ID generation, caching, analytics |
| Chat system | WebSockets, presence, message ordering |
| News feed | Fan-out, ranking, personalization |
| Rate limiter | Sliding window, distributed state |
| Notification system | Multi-channel, retry, scheduling |
| File storage (Dropbox) | Chunking, sync, deduplication |
| Search engine | Inverted index, ranking, crawling |
| Payment system | Idempotency, reconciliation, fraud |
Practice Exercises¶
- Design a Twitter-like feed — handle writes from 100K users, reads from 10M users.
- Design a chat application — 1:1 and group chat with read receipts and typing indicators.
- Design a job queue — reliable, distributed, with retry and dead-letter queue.
- Design a rate limiter — multiple algorithms (fixed window, sliding window, token bucket).
- Design a notification service — email, push, SMS with batching and user preferences.
💬 Discussion
Have a question about this topic? Found an error? Share your thoughts below.