gavel

Phase 0:
The Interview Protocol

System design is not just about drawing boxes; it is a test of your ability to manage ambiguity, communicate choices, and justify trade-offs under pressure.

The 45-Minute Breakdown

Time management is the most common reason senior engineers fail. Here is how to pace yourself:

help_outline
0-5 min

Clarify Requirements

schema
5-10 min

High-Level Design

analytics
10-35 min

Deep Dives

rocket_launch
35-45 min

Wrap-up & Scaling

Step 1: Clarification & Constraints

quizWhat to Ask

  • • Who are the users? (Internal vs. External)
  • • What are the core features? (Scope creep is your enemy)
  • • Growth expectations over 1-5 years.
  • • Consistency vs. Availability (The CAP Theorem choice).

The "Capacity" Section

You MUST write these down on the board:

  • • DAU (Daily Active Users): 100M
  • • Reads vs Writes: 100:1 (Read heavy)
  • • RPS (Requests per second): ~1k to 10k
  • • Storage: ~10 TB over 3 years

Step 2: High-Level Design

inventory_2

The "Box and Arrow" Layout

Don't worry about specific DB technologies yet. Focus on the data flow. Every system design typically follows these building blocks:

Client
arrow_forward
Load Balancer / API Gateway
arrow_forward
Application Servers
arrow_forward
Database / Cache

"Goal: Get the entire flow from User Request to Response on the board quickly."

Step 3: Deep Dives

Focus on the Hardest Part

Every interview has one core problem that the interviewer wants to see you solve.

  • boltURL Shortener: ID Generation Collisions
  • boltUber: Geo-spatial indexing / Sharding
  • boltChat/Social: Notification Fan-out

Standard Deep Dive Topics

Be prepared to discuss these in any system:

• Cache Invalidation
• DB Partitioning
• Replication Lag
• Rate Limiting

Step 4: Wrap-up & Trade-offs

Never leave the interview with a "Perfect Solution." Architects know that every choice takes away something else. Conclude by mentioning the bottlenecks you still see.

1. Scaling

"If traffic triples, our bottleneck will be the global DB write lock..."

2. Failure Modes

"If our message broker goes down, we might lose some secondary metrics analytics..."

3. Trade-offs

"We chose eventual consistency to ensure high write availability for users..."

The Verbal Template

campaign

How to Explain your Architecture

Use the Requirement → Technology → Trade-off chain for every choice.

"Since our system is read-heavy, I'll use Redis as a caching layer to reduce DB latency, though this introduces the challenge of cache invalidation."