Vague prompts like “Design Twitter,” “Design Uber,” or “Build a URL shortener” can feel overwhelming without direction. What do you prioritize? Where do you even begin your diagram?
The solution isn’t memorizing architectures—it’s developing a consistent methodology. Once you have a repeatable process, any system design question becomes manageable. You shift from reactive scrambling to confident problem-solving.
The 5-Step Framework
Follow This Every Time
Clarify functional & non-functional requirements. Ask questions.
Back-of-envelope math. Users, QPS, storage, bandwidth.
Draw the main components. API design. Data flow.
Dive into critical components. Database schema. Caching. Scaling.
Discuss trade-offs. Bottlenecks. Future improvements.
Step 1: Requirements Gathering
Questions to Ask
Functional
- • What are the core features?
- • Who are the users?
- • What are the main use cases?
- • Any features we should skip?
Non-Functional
- • How many users/DAU?
- • Availability requirements?
- • Latency expectations?
- • Consistency vs. availability?
Step 2: Back-of-Envelope Estimations
Key Numbers to Calculate
QPS (Queries Per Second)
DAU × actions per day ÷ 86,400 seconds
Example: 100M DAU × 10 actions = 1B/day ≈ 12,000 QPS
Storage
Object size × objects per day × retention period
Example: 1KB × 1B/day × 365 days = 365 TB/year
Bandwidth
QPS × object size
Example: 12,000 QPS × 1KB = 12 MB/s
Useful Conversions
- • 1 day = 86,400 seconds ≈ 100K seconds
- • 1 million/day ≈ 12/second
- • 1 billion/day ≈ 12,000/second
Essential Components Cheat Sheet
Load Balancer
Distributes traffic across servers. Use for horizontal scaling.
When: Multiple servers, high availability needs
Types: Round robin, least connections, IP hash, weighted
Caching
Reduce latency and database load by storing frequent data in memory.
Tools: Redis, Memcached
Strategies: Cache-aside, write-through, write-behind
Invalidation: TTL, on update, LRU eviction
Database Selection
SQL (PostgreSQL, MySQL)
- • Structured data, relationships
- • ACID transactions needed
- • Complex queries
NoSQL (MongoDB, Cassandra)
- • Flexible schema
- • High write throughput
- • Horizontal scaling priority
CDN (Content Delivery Network)
Serve static content from edge locations close to users.
When: Static assets (images, videos, JS/CSS), global users
Examples: CloudFront, Cloudflare, Akamai
Database Scaling Patterns
Replication
Master-slave. Writes to master, reads from replicas. Good for read-heavy workloads.
Sharding
Split data across multiple databases. Shard by user_id, geographic region, etc.
Denormalization
Duplicate data to avoid joins. Trade storage for read performance.
Common Design Patterns
Decouple services, handle async tasks. Kafka, RabbitMQ, SQS.
One-to-many messaging. Real-time updates, notifications.
Token bucket, leaky bucket, sliding window. Protect against abuse.
Distribute data across nodes. Minimize redistribution when nodes change.
Prevent cascade failures. Stop calling failing services temporarily.
Example: Design a URL Shortener
Quick Solution Outline
Requirements
- • Shorten URLs, redirect to original
- • 100M URLs created/day, 1B redirects/day
- • Low latency (<100ms), high availability
Estimations
- • Write QPS: 100M/day ≈ 1,200/s
- • Read QPS: 1B/day ≈ 12,000/s (10:1 read:write)
- • Storage: 500 bytes × 100M × 365 × 5 years ≈ 100TB
Key Design Decisions
- • Short code: Base62 encoding, 7 chars = 3.5T combinations
- • Database: NoSQL (DynamoDB/Cassandra) for high writes
- • Caching: Redis for hot URLs
- • ID generation: Twitter Snowflake or pre-generated IDs
Practice Articulating Your Design
System design is about communication, not just architecture. Craqly helps you practice explaining your designs clearly.
The Bottom Line
System design interviews are learnable. Follow the framework, practice common problems, and focus on trade-offs. You don’t need to know every possible technology—you need to reason about systems effectively.
Print this cheat sheet. Review before interviews. And remember: the interviewer wants to see how you think, not a perfect answer.