How to Communicate

The Framework: Task → Approach → Results → Improvements

Amazon system design interviews are 45 minutes. Without structure, you'll either rush through superficially or get lost in one component. Use this framework for every question:

Phase 1: Clarify Requirements (5 minutes)

Before drawing anything, ask questions. This is not wasted time — it's signal that you think before building.

Questions to ask:

• What are the core use cases? (read-heavy? write-heavy? real-time?)
• What is the scale? (users, QPS, data volume)
• What are the latency requirements? (real-time? batch? acceptable delay?)
• What consistency guarantees are needed? (strong vs. eventual)
• Are there specific constraints? (budget, existing infrastructure, regulatory)

Example dialogue:

"Before I start designing, I'd like to clarify the requirements. Are we building for reads, writes, or both? What's the expected scale in terms of daily active users and queries per second?"

Phase 2: High-Level Estimation (5 minutes)

Estimate scale to drive your design decisions. You don't need exact numbers — ballpark is fine.

100M daily active users
10 requests per user per day = 1B requests/day
1B / 86400 seconds ≈ 12,000 QPS peak ≈ 25,000 QPS peak (2x average)

Storage: 1B requests * 1KB average = 1TB/day = 365TB/year

These numbers drive decisions:

• 25K QPS → need load balancer + multiple app servers
• 365TB/year → need distributed storage (S3, DynamoDB, partitioned RDS)
• Read-heavy → add caching layer

Phase 3: Design the Architecture (20 minutes)

This is the core of the interview. Work from left to right:

1. Client → Load Balancer: how traffic enters the system
2. Load Balancer → Application Layer: compute tier, auto-scaling
3. Application → Data Layer: databases, caches, message queues
4. Data Layer internals: replication, partitioning, consistency

For each component, explain:

• What it does (brief)
• Why you chose it (justification)
• What alternatives exist (tradeoffs)

Phase 4: Deep Dive (10 minutes)

The interviewer will ask you to go deeper on specific areas:

• Database schema design
• Specific API design
• Caching strategy
• Failure scenarios
• Consistency model

Be ready to zoom into any component. Have mental "depth" ready for each layer.

Phase 5: Tradeoffs & Improvements (5 minutes)

Summarize your design with tradeoffs:

• What did you choose and why?
• What are the limitations?
• What would you do differently at larger scale?
• What failure scenarios exist and how would you handle them?

STAR-like for System Design

STAR Element	System Design Equivalent	Example
Situation	Context & constraints	"We need a URL shortener for 100M daily users"
Task	Requirements & scale	"100M URLs/day, read-heavy, 100:1 read:write ratio"
Action	Architecture & decisions	"I'll use DynamoDB for storage, Redis for caching"
Result	Tradeoffs & analysis	"This gives us O(1) reads, eventual consistency for writes"
Improvement	Future scaling	"At 10x scale, I'd add CDN and multi-region"

Think Out Loud While Drawing

The diagram is a communication tool, not an art project. Draw while explaining — don't draw silently for 5 minutes then present.

Bad approach: (silent drawing for 3 minutes)

"Here's my design." (interviewer has no context)

Good approach: (drawing while narrating)

"Let me start with the client side. We have mobile and web clients that send requests to a load balancer..." (draws client → LB)
"The load balancer distributes traffic across our application servers..." (draws LB → app servers)
"Now for the data layer, I'm going to use DynamoDB for our primary storage because..." (draws app → DynamoDB)

Diagram Best Practices

1. Label everything. Don't draw boxes without text. Every component should have a name.

2. Use consistent shapes. Pick a convention and stick to it:

   • Rectangles: application servers, services
   • Cylinders: databases, storage
     n - Diamonds: load balancers, caches
     n - Arrows: data flow direction

3. Show data flow direction. Arrows should indicate which direction data moves. Label bidirectional flows.

4. Add key details. Write important numbers or config next to components:

   • "Redis (cache)" not just "Redis"
   • "DynamoDB (partitioned by userId)" not just "DynamoDB"
   • "3 AZs" next to your deployment

5. Group related components. Use dotted boxes or shading to show logical groupings:

   • "Application Tier" box around app servers
   • "Data Tier" box around databases and caches
   • "AWS Region" box around everything

Common Diagram Mistakes

Mistake	Why It's Bad	Fix
No labels	Interviewer can't follow	Label every component
Too detailed	Overwhelming, lose the big picture	Start high-level, add detail in deep-dive
Too simple	Looks like you haven't thought it through	Include replication, caching, queues
No data flow	Hard to understand how system works	Draw arrows with labels
UML notation	Overly formal, wastes time	Simple boxes and arrows are fine

Diagram Progression

Start simple, add complexity as you discuss:

Minute 3: Basic flow — Client → LB → App → DB
Minute 8: Add caching — Client → LB → App → Cache → DB
Minute 12: Add async processing — Client → LB → App → Cache → DB + App → Queue → Worker → DB
Minute 18: Add replication — DB with read replicas, cache cluster

This progression shows your thinking evolving and prevents overwhelm.

What to Draw First

1. Stick figures or rectangles for clients (mobile, web, IoT)
2. Single box for load balancer
3. 2-3 boxes for application servers (showing it's distributed)
4. Cylinder for primary database
5. Then refine: add cache, queues, replicas, CDNs as needed

Narration: Explain WHY, Not Just WHAT

The biggest mistake candidates make is listing components without explaining reasoning.

Bad narration:

"I'll use Redis for caching, DynamoDB for the database, and SQS for the queue."
(No justification, no alternatives discussed)

Good narration:

"For caching, I'll use Redis. The reason is our access pattern is read-heavy — 90% reads, 10% writes. Redis gives us sub-millisecond latency for hot data. An alternative would be Memcached, but Redis also supports data structures we need for the leaderboard feature. The cache invalidation strategy would be write-through for consistency."

Narration template for each component:

1. What: "I'm choosing [technology]"
2. Why: "because [justification based on requirements]"
3. Tradeoff: "the tradeoff is [limitation], which we accept because [reason]"
4. Alternative: "alternatively, we could use [other], but [why it's worse for this case]"

Confidence Signals

Things that signal confidence:

• Speaking at a steady pace (not rushing)
• Making eye contact while explaining
• Drawing while narrating (not drawing silently)
• Acknowledging tradeoffs openly: "This approach has X limitation, but we accept it because Y"
• Asking clarifying questions (shows you think before building)

Things that signal uncertainty:

• Speaking too fast (rushing through to hide gaps)
• Drawing complex diagrams without explaining
• Saying "I don't know" to everything (one "I don't know" is fine, but not multiple)
• Being defensive when challenged

Handling "I Don't Know"

It's okay to not know everything. What matters is how you handle it:

Good response:

"I'm not deeply familiar with the internals of [X], but based on my understanding of [related concept], I'd approach it this way... After the interview, I'd research [specific topic] to understand the details."

Bad response:

"I don't know." (then silence)

The key is to show your thinking process even when you lack specific knowledge.

Time Management

45-Minute Breakdown:

Phase	Time	What to Do
Clarify	5 min	Ask 2-3 targeted questions about requirements
Estimate	5 min	Quick back-of-envelope math
Design	20 min	Build the architecture layer by layer
Deep Dive	10 min	Go deeper on whatever the interviewer asks
Tradeoffs	5 min	Summarize, discuss limitations, mention improvements

Warning signs you're off track:

• You've spent 10+ minutes on requirements → start designing
• You're 15 minutes in and haven't drawn anything → start drawing
• You're 30 minutes in and still on high-level → time for deep-dive
• You're 40 minutes in and haven't discussed tradeoffs → wrap up

Pacing checkpoints:

• Minute 5: Requirements clear, estimation done
• Minute 10: Basic architecture drawn
• Minute 20: Architecture detailed with caching, queues
• Minute 30: Deep-dived on 1-2 key areas
• Minute 40: Tradeoffs and improvements discussed
• Minute 45: Done

Amazon-Specific Communication

Amazon values structured thinking and customer obsession in communication:

1. Start with the customer: "The user needs to be able to..."
2. Use data: Reference your estimates throughout ("At 25K QPS, we need...")
3. Be explicit about tradeoffs: Amazon culture values data-driven decisions
4. Think long-term: Mention how the design scales as requirements grow
5. Be concise: Amazon's leadership principle "Have Backbone; Disagree and Commit" — state your position clearly

Common Communication Pitfalls

Pitfall	Impact	Fix
Jumping into design without requirements	Build wrong thing	Always clarify first
Only listing technologies	No depth, no justification	Explain WHY for each choice
Ignoring interviewer hints	Miss key constraints	Listen for their follow-up questions
Over-engineering	Waste time on complexity	Start simple, add complexity as needed
Under-engineering	Miss critical components	Cover: LB, app, DB, cache, queue
Monologuing	No engagement	Pause, ask if they want to go deeper on X
Arguing with interviewer	Bad signal	Acknowledge their point, incorporate if valid