Mastering the System Design Interview

Phase 1: Requirements Clarification (5 minutes)

Never start drawing boxes. Start by asking questions. This demonstrates engineering discipline and prevents wasted effort on the wrong problem.

Questions to always ask:

• "How many daily active users are we designing for?"
• "What's the read vs write ratio?"
• "Is this a global system or single-region?"
• "What are our availability and latency SLAs?"
• "Are there any existing systems we need to integrate with?"
• "Do we need to support mobile clients, web, or both?"

After their answers, restate your understanding: "So we're designing for 50M DAU, read-heavy at 100:1, with a 99.9% availability target and sub-200ms latency globally. Let me start with capacity estimation."

Phase 2: Capacity Estimation (3–5 minutes)

Quick back-of-envelope math that anchors every subsequent decision. This is what separates senior engineers from juniors — the ability to reason quantitatively about scale.

The numbers you need to know:

• 1M users × 10 actions/day = 10M requests/day = ~115 requests/second (QPS)
• Peak QPS is typically 2–3x average
• 1 character = 1 byte | 1KB = 1,000 bytes | 1MB = 1,000KB | 1GB = 1,000MB
• A typical tweet/post: ~300 bytes | A photo: ~300KB | A video minute: ~50MB
• PostgreSQL handles ~10K–50K QPS on a single node before needing scaling
• Redis handles ~1M ops/second on a single node

Phase 3: High-Level Design (10–15 minutes)

Draw the system from client to storage, explaining each component as you add it.

Standard components to consider for every system:

• DNS + CDN: Route traffic globally, serve static assets from edge
• Load Balancer: Distribute traffic across application servers (L7 for HTTP-aware routing)
• Application Servers: Stateless, horizontally scalable, containerized
• Database: SQL for transactional data, NoSQL for scale-out, time-series for metrics
• Cache (Redis/Memcached): L1 cache between app and DB for read-heavy paths
• Message Queue (Kafka/SQS): Async processing, decouple producers from consumers
• Object Storage (S3): Unstructured data — images, videos, files
• Search Engine (Elasticsearch): Full-text search, analytics

Phase 4: Deep Dive (10–15 minutes)

The interviewer will guide you to explore 2–3 components in detail. This is where your depth shows. For each component, discuss:

• Internal design and data structures
• Failure modes and how you handle them
• Scaling approach as load grows
• Trade-offs vs alternatives

The 5 Trade-offs You Must Know Cold

1. SQL vs NoSQL

Choose SQL when: you need ACID transactions, complex queries with JOINs, and a well-defined schema. Choose NoSQL when: you need horizontal scaling, flexible schema, high write throughput, or document/graph data models. The answer is almost always "both" in large systems — SQL for user accounts and transactions, NoSQL for feeds, events, and logs.

2. Strong Consistency vs Eventual Consistency (CAP Theorem)

In a distributed system, during a network partition you must choose between Consistency (all nodes return the same data) and Availability (all nodes respond, possibly with stale data). Choose strong consistency for banking, inventory, and seat reservations. Choose eventual consistency for social media feeds, like counts, and recommendation systems.

3. Synchronous vs Asynchronous Processing

Sync: simpler, immediate feedback, but caller blocks waiting for response. Use for: payment confirmation, login, form submission. Async (via message queues): higher throughput, better fault tolerance, but eventual processing. Use for: email sending, image resizing, report generation, notification dispatch.

4. Push vs Pull (for feed/notification systems)

Push (fan-out on write): pre-compute results when data is produced. Fast reads, expensive writes for high-follower accounts. Pull (fan-out on read): compute on demand. Cheap writes, expensive reads. Hybrid: push for regular users, pull for celebrities, merge at read time.

5. Monolith vs Microservices

Monolith: simpler development, single deployment, no network overhead. Best for early-stage or small teams. Microservices: independent scaling, deployment, and failure isolation. Best for large systems with distinct ownership boundaries. Don't over-engineer early — many great systems started as monoliths and decomposed strategically.

Common System Design Interview Questions by Category

Category	Example Questions	Key Concepts
Storage Systems	Design Dropbox, S3, HDFS	Chunking, replication, consistency
Communication Systems	Design WhatsApp, Slack, email	WebSockets, fan-out, presence
Social Systems	Design Twitter, Instagram, LinkedIn	Feed ranking, social graph, search
Transaction Systems	Design Stripe, Uber, booking	ACID, idempotency, saga pattern
Infrastructure	Design rate limiter, CDN, cache	Algorithms, sharding, eviction

How to Practice System Design Interviews Effectively

Reading about system design is necessary but not sufficient. You need to practice verbalizing your architectural decisions in real time, responding to follow-up questions, and adapting when constraints change. MockExperts' System Design Drawing mode gives you an interactive whiteboard where you can diagram components, explain your choices, and receive structured AI feedback on your design completeness, trade-off reasoning, and communication clarity. Each session mirrors the real interview format — exactly what you need to internalize the 4-phase framework above.