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

Requirements (5 min)

Clarify functional & non-functional requirements. Ask questions.

Estimations (5 min)

Back-of-envelope math. Users, QPS, storage, bandwidth.

High-Level Design (10 min)

Draw the main components. API design. Data flow.

Deep Dive (15 min)

Dive into critical components. Database schema. Caching. Scaling.

Wrap-up (5 min)

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

Message Queue

Decouple services, handle async tasks. Kafka, RabbitMQ, SQS.

Pub/Sub

One-to-many messaging. Real-time updates, notifications.

Rate Limiting

Token bucket, leaky bucket, sliding window. Protect against abuse.

Consistent Hashing

Distribute data across nodes. Minimize redistribution when nodes change.

Circuit Breaker

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.

System Design Interview Quick Reference: Essential Templates & Best Practices 2026