System Design Series Part 15: Questions & Trade-off Analysis

System Design Questions & Trade-off Analysis

Series Navigation: This is Part 15 (Final Part) of the System Design Series. Review Part 14: Authentication & Security for context on security trade-offs.

System Design Mastery

Your 15-step learning path • Currently on Step 15

15

Questions & Trade-offs

Common questions, SQL vs NoSQL, push vs pull

You Are Here

System design questions test your ability to reason about large-scale distributed systems. They require applying the concepts covered throughout this series — scalability, caching, databases, messaging, and consistency — to concrete problems with real-world constraints and trade-offs.

                        
                        Key Insight: There's no single "correct" design. Great system designs make deliberate trade-offs that match specific requirements and constraints. Understanding WHY you choose one approach over another is what differentiates strong architectural thinking.
                    

Each question below exercises core system design skills:

Decomposing complex systems into manageable components
Selecting appropriate data stores and communication patterns
Making and justifying trade-off decisions
Reasoning about scale, latency, and reliability
Identifying bottlenecks and mitigation strategies

Common System Design Questions

These are frequently encountered system design problems, organized by complexity. Each walks through the key design decisions, data flow, and scaling considerations:

Easy

Design a URL Shortener (like bit.ly)

Key Points: Hashing algorithms, database schema, read-heavy workload, caching, analytics

# Key Design Decisions
"""
1. SHORTENING ALGORITHM:
   - Base62 encoding (a-z, A-Z, 0-9) = 62^7 = 3.5 trillion URLs
   - Use auto-increment ID ? Base62 (simple)
   - Or MD5 hash ? take first 7 chars (collision handling needed)

2. READ VS WRITE:
   - Reads >> Writes (100:1 ratio typical)
   - Cache popular URLs in Redis
   - Reads hit cache first, then database

3. SCALE ESTIMATION (1B URLs/year):
   - Writes: 1B/year = 30 URLs/sec
   - Reads: 30 × 100 = 3,000 QPS (easy for single DB + cache)

4. DATABASE SCHEMA:
   CREATE TABLE urls (
       short_code VARCHAR(7) PRIMARY KEY,
       original_url TEXT NOT NULL,
       user_id INT,
       created_at TIMESTAMP,
       expires_at TIMESTAMP,
       click_count INT DEFAULT 0
   );

5. API DESIGN:
   POST /shorten ? {"short_url": "bit.ly/abc123"}
   GET /{short_code} ? 301 Redirect to original URL
"""

Medium

Design a Chat System (like WhatsApp/Slack)

Key Points: WebSockets, message delivery guarantees, presence, group chat, read receipts

# Key Design Decisions
"""
1. REAL-TIME DELIVERY:
   - WebSocket for persistent connections
   - Each user maintains connection to chat server
   - Server pushes messages instantly

2. MESSAGE DELIVERY GUARANTEES:
   - At-least-once delivery (retry until ACK)
   - Message states: sent ? delivered ? read
   - Client sends ACK, server updates status

3. OFFLINE HANDLING:
   - Store messages in queue if recipient offline
   - Deliver when they reconnect
   - Push notification via APNS/FCM

4. GROUP CHAT SCALING:
   - Fan-out on write for small groups (< 100 members)
   - Fan-out on read for large groups (channels)
   - Cache group membership

5. ARCHITECTURE:
   Client ? WebSocket Gateway ? Chat Service ? Database
                    ?
              Message Queue ? Push Notification Service
                    ?
              Presence Service (online/offline status)
"""

Hard

Design a News Feed (like Facebook/Twitter)

Key Points: Fan-out, ranking algorithms, timeline generation, caching strategy

# Key Design Decisions
"""
1. FAN-OUT STRATEGY:
   Push Model:
   - Write to all followers' feeds on post
   - Fast reads, slow writes
   - Problem: Celebrities with millions of followers
   
   Pull Model:
   - Fetch from all followed users on read
   - Fast writes, slow reads
   - Problem: Many queries per read
   
   Hybrid (Recommended):
   - Push for normal users
   - Pull for celebrities (>10K followers)
   - Merge at read time

2. FEED STORAGE:
   - User timeline in Redis sorted set
   - Key: user:{id}:feed
   - Value: post_id, Score: timestamp
   - ZREVRANGE for recent posts

3. RANKING ALGORITHM:
   score = (likes × 2) + (comments × 3) + recency_decay
   - Filter: Spam, blocked users, seen content
   - Personalize: Interest model, engagement history

4. SCALE:
   - 500M DAU × 100 feed views = 50B reads/day
   - Cache hot feeds, pre-compute for active users
   - Shard by user_id
"""

Medium

Design a Notification System

Key Points: Push/email/SMS channels, priority queues, rate limiting, user preferences

# Key Design Decisions
"""
1. MULTI-CHANNEL DELIVERY:
   - Push (iOS/Android), Email, SMS, In-app
   - User preferences per notification type
   - Channel fallback (push failed ? email)

2. ARCHITECTURE:
   Event Source ? Notification Service ? Channel Routers
                                              ?
   +-----------------------------------------------------+
   ¦  Push Service  ¦  Email Service  ¦  SMS Service    ¦
   ¦  (APNS/FCM)    ¦  (SendGrid)     ¦  (Twilio)       ¦
   +-----------------------------------------------------+

3. PRIORITY HANDLING:
   - High: Security alerts, payment confirmations
   - Medium: Social interactions, updates
   - Low: Marketing, recommendations
   - Separate queues per priority level

4. RATE LIMITING:
   - Per-user: Max 10 notifications/hour
   - Per-channel: Respect provider limits
   - Batching: Group similar notifications

5. DEDUPLICATION:
   - Cache recently sent notifications
   - Idempotency key per notification
   - Prevent duplicate sends on retry
"""

Trade-off Discussions

Every design decision involves trade-offs. Be ready to discuss them explicitly.

SQL vs NoSQL

Factor	SQL (PostgreSQL, MySQL)	NoSQL (MongoDB, Cassandra)
Schema	Fixed schema, migrations required	Flexible schema, evolves easily
Relationships	JOINs are first-class	Denormalize or application joins
Transactions	ACID guaranteed	Limited (varies by product)
Scaling	Vertical, or complex sharding	Horizontal scaling built-in
Use When	Complex queries, strong consistency	High write volume, flexible data

Push vs Pull Architecture

Factor	Push (Fan-out on Write)	Pull (Fan-out on Read)
Latency	Fast reads (pre-computed)	Slower reads (computed on demand)
Write Cost	High (N writes per post)	Low (1 write per post)
Hotspot	Celebrity problem (millions of writes)	Hot content (many reads)
Freshness	Eventually consistent	Always fresh
Use When	Read-heavy, small follower counts	Write-heavy, large follower counts

Next Steps

You've explored common system design questions and the critical trade-offs that shape architectural decisions. Apply these patterns across the series topics — from scalability and caching to microservices and distributed systems.

System Design Series Part 15: Questions & Trade-off Analysis

Table of Contents

System Design Questions & Trade-off Analysis

System Design Mastery

Introduction to System Design

Scalability Fundamentals

Load Balancing & Caching

Database Design & Sharding

Microservices Architecture

API Design & REST/GraphQL

Message Queues & Event-Driven

CAP Theorem & Consistency

Rate Limiting & Security

Monitoring & Observability

Real-World Case Studies

Data Modeling & Schema Design

Distributed Systems Deep Dive

Authentication & Security