Loading learning content...
Every system design rests on a foundation of assumptions. Some are explicit—you asked the interviewer and got an answer. But many are implicit: the choices you make unconsciously based on experience, intuition, or convention.
Implicit assumptions are invisible traps.
You assume write traffic is evenly distributed throughout the day, but the interviewer imagines a social platform with viral spikes. You assume users tolerate 500ms latency, but the interviewer expected a gaming application with 50ms budgets. You assume strong consistency because "that's how databases work," but the interviewer wanted to see you reason about eventual consistency.
The solution: make assumptions explicit, document them visibly, and use them strategically.
Documenting assumptions isn't defensive or bureaucratic—it's a professional practice that demonstrates engineering maturity. Principal engineers don't just have better intuitions; they externalize their reasoning so others can verify, challenge, and align.
By the end of this page, you will master the skill of assumption documentation: identifying hidden assumptions, categorizing them by risk, communicating them effectively, using them to justify design decisions, and updating them as the interview progresses.
In professional engineering, undocumented assumptions are the root cause of countless misalignments between what teams build and what stakeholders need. In interviews, they cause the same problem in miniature.
The Assumption Gap Problem:
You and the interviewer each hold mental models of the system. Without explicit assumptions, these models diverge silently. By the end of the interview, you've designed a perfectly valid system for requirements the interviewer never had.
When these mental models diverge, both parties are frustrated. The candidate feels they delivered a solid design; the interviewer feels they missed key requirements. Both are right—the problem was the invisible assumptions.
The Solution: Radical Transparency
By stating assumptions explicitly, you:
When you state an assumption, you're not just documenting—you're inviting dialogue. 'I'm assuming eventual consistency is acceptable' is both a declaration and a question. Strong interviewers will engage with this, either confirming or redirecting.
Assumptions are not monolithic. They vary in type, risk, and impact. Understanding these categories helps you identify, document, and manage them effectively.
The Four Categories:
| Category | Example Assumptions | Design Impact |
|---|---|---|
| Traffic | 100:1 read-to-write ratio, 10K RPS peak, steady growth | Caching strategy, database replication, capacity planning |
| Technical | AWS infrastructure, Redis for caching, PostgreSQL for storage | Service boundaries, technology choices, operational approach |
| Business | Eventual consistency acceptable, 99.9% availability, MVP first | CAP trade-offs, redundancy investment, phasing |
| Environmental | Greenfield project, experienced team, no legacy integration | Architecture freedom, technology choices, complexity tolerance |
Not all assumptions carry equal risk. A wrong traffic assumption (1M vs 100M users) changes the entire architecture. A wrong technology assumption (Redis vs Memcached) is usually easy to adjust. Focus documentation energy on high-risk assumptions.
The hardest assumptions to document are the ones you don't know you're making. These implicit assumptions feel like "obvious truths" precisely because they're invisible to you.
Techniques for Surfacing Hidden Assumptions:
1. The "Why This?" Technique For every design decision, ask yourself: "Why this choice and not an alternative?" The answer usually reveals an underlying assumption.
2. The "What If?" Technique Consider the opposite of your intuition:
If these alternatives would change your design, you've found assumptions worth documenting.
3. The "First Principles" Technique Start from fundamental questions:
123456789101112131415161718192021222324252627
**Decision:** Use a fan-out-on-write approach (precompute timelines) **Surface Hidden Assumptions:** "Why This?"- Why not fan-out-on-read? → Assumption: Read latency is more critical than write latency → Assumption: Storage is cheaper than compute at read time "What If?"- What if users followed 1M accounts? → Assumption: Users follow reasonable number of accounts (<5K)- What if most content was never read? → Assumption: Content has high read probability "First Principles?"- How big are timelines? → Assumption: Timelines hold ~1000 recent posts- How often are timelines accessed? → Assumption: Timelines accessed more often than posts are created **Documented Assumptions:**1. Read latency is prioritized over write latency2. Users follow < 5,000 accounts on average 3. Most content gets read at least once4. Timelines are capped at recent 1,000 posts5. Storage is more cost-effective than compute at scaleThe more experienced you are, the more assumptions become invisible. What feels like 'obvious' system design is actually years of accumulated assumptions. Deliberately slow down and question your intuitions—especially the ones that feel most natural.
How you document assumptions affects their utility. Random notes are hard to reference; structured documentation is powerful.
The Structured Assumption Format:
For each significant assumption, document:
123456789101112131415161718192021
**ASSUMPTIONS:** [A1] Read-heavy workload (100:1 read-to-write ratio) Rationale: Typical for content consumption platforms Impact: Aggressive caching, read replicas If wrong: Would need write optimization, different DB choice [A2] Eventual consistency acceptable for feed Rationale: Users tolerate few seconds of staleness Impact: Async fanout, simpler replication If wrong: Synchronous writes, consensus protocol needed [A3] Single region deployment (US) Rationale: Initial launch scope; multi-region is Phase 2 Impact: Simpler architecture, lower latency in-region If wrong: Need global load balancing, multi-master replication [A4] Users have < 1000 followers on average Rationale: Long-tail distribution typical for social Impact: Fanout-on-write is viable If wrong: Hybrid fanout strategy needed for celebritiesVisible Documentation:
In interviews, write assumptions where the interviewer can see them:
This visibility serves multiple purposes:
Document the assumptions that matter, not every trivial choice. 'I assume the system runs on computers' is not useful. Focus on assumptions that significantly affect the design or where misalignment would be costly.
Documentation without communication is incomplete. The way you verbalize assumptions affects how interviewers perceive and respond to them.
Communication Patterns:
1. The Declaration Pattern "I'm going to assume [X]. This means [design implication]."
Best for: Clear, non-controversial assumptions Example: "I'm going to assume we're in a single region initially. This means I can use a simpler replication strategy."
2. The Proposal Pattern "I'm thinking [X]—does that align with what you had in mind?"
Best for: Risky or significant assumptions you want verification on Example: "I'm thinking eventual consistency is acceptable for the feed—does that align with what you had in mind?"
3. The Conditional Pattern "If [X], then [design choice]. If [not X], we'd need to [alternative]."
Best for: Showing flexibility and awareness of alternatives Example: "If this is read-heavy, I'll add a caching layer. If it's write-heavy, we'd need a different approach—I can pivot if needed."
When to State Assumptions:
Link assumptions to design decisions explicitly: 'Because I'm assuming [A1] read-heavy traffic, I'm adding a Redis caching layer here.' This makes your reasoning chain visible and traceable. Interviewers love seeing explicit cause-and-effect thinking.
Documented assumptions are powerful tools for justifying design decisions. When an interviewer asks "Why did you choose X?", you can point to an assumption and explain the reasoning chain.
The Justification Chain:
Assumption → Design Principle → Specific Choice
Example:
1234567891011121314151617181920212223242526272829303132
**Question:** "Why are you using eventual consistency here?" **Strong Answer (Assumption-Based):**"Great question. Looking back at assumption A2—that users tolerate a few seconds of staleness in their feed—eventual consistency lets us decouple the write path from the read path. This means post creation can return immediately without waiting for all followers' feeds to update. The trade-off is that a follower might not see a post for 2-3 seconds after creation. If assumption A2 were wrong—if users expected instant propagation—I'd switch to synchronous fanout with a different latency/consistency trade-off." --- **Question:** "Why a sharded database and not just vertical scaling?" **Strong Answer:**"Based on assumption A3—that we're targeting 500M users with 1B posts—we're looking at petabyte-scale storage and millions of queries per second. Vertical scaling has a ceiling (biggest server you can buy), and it's a single point of failure. Sharding by user ID gives us horizontal scalability and fault isolation—if one shard fails, only a subset of users are affected. If assumption A3 changed—if we only needed 1M users—a single PostgreSQL instance with read replicas might suffice, which would be operationally simpler."Notice how each justification ends with 'If the assumption were wrong...' This signals flexibility and avoids sounding dogmatic. It shows you understand that different assumptions lead to different designs—a mark of senior thinking.
Sometimes you discover mid-interview that an assumption was wrong. Maybe the interviewer corrects you, or you realize a contradiction. How you handle this reveals maturity.
Common Scenarios:
1. Interviewer Corrects You "Actually, we need strong consistency for this."
Response Pattern:
123456789101112131415161718192021222324
**Situation:** You designed with eventual consistency, interviewer says strong consistency is required. **Strong Response:**"Ah, good to know—let me update my assumptions. [Visibly updates A2 to 'Strong consistency required'] This changes things significantly. My async fanout approach won't work because followers need to see posts immediately with guaranteed ordering. I'd need to switch to synchronous writes with a consensus protocol—probably Raft-based replication. This adds latency to the write path but guarantees that once a post is confirmed, all replicas have it. [Adjusts diagram] The fanout service now becomes synchronous, and I'd add a quorum write requirement here..." **Why This Works:**- Acknowledges the correction without embarrassment- Updates documentation visibly- Traces the design impact clearly- Pivots to the new design confidently2. You Discover an Internal Contradiction Sometimes your own design reveals that two assumptions conflict.
"Wait—I assumed low latency AND global distribution, but those are in tension..."
Response Pattern:
Example: "I realize I've been assuming both global users and sub-50ms latency. Physics makes that impossible—light takes 70ms to cross the Atlantic. Let me clarify: which is the priority? If latency is critical, we'd need regional isolation. If global access is critical, we accept higher latency for distant users."
Catching your own assumption conflicts before the interviewer does demonstrates self-awareness and rigorous thinking. Don't be afraid to say 'Wait, I need to reconsider...'—this is a strength, not a weakness.
Sophisticated candidates don't just document assumptions—they analyze their sensitivity. Which assumptions, if wrong, would fundamentally break the design? Which are relatively safe?
The Sensitivity Matrix:
For each assumption, evaluate:
High-impact, uncertain assumptions deserve extra attention.
| Assumption | Confidence | Impact if Wrong | Sensitivity |
|---|---|---|---|
| Read-heavy (100:1) | High (typical for social) | Major (cache strategy) | ⚠️ Medium |
| Single region | Confirmed by interviewer | Major (replication) | ✅ Low |
| < 1000 followers average | Medium (long tail assumed) | Major (fanout strategy) | 🔴 High |
| Users accept 3s staleness | Low (not confirmed) | Major (consistency) | 🔴 High |
| PostgreSQL for storage | High (reasonable default) | Low (swappable) | ✅ Low |
Communicating Sensitivity:
For high-sensitivity assumptions, explicitly acknowledge the risk:
"My design heavily depends on assumption A4—that users have fewer than 1000 followers on average. If there are many users with millions of followers, the fanout-on-write approach breaks down, and I'd need a hybrid strategy. Want me to design for that case instead?"
This shows:
The best designs are robust to assumption changes—they don't fall apart if one assumption is slightly off. When analyzing sensitivity, consider: 'Does this design degrade gracefully if assumptions are wrong, or does it catastrophically fail?' Graceful degradation is a mark of mature design.
Assumptions aren't static. They evolve throughout the interview as you design, discover conflicts, and receive feedback. Managing this lifecycle is key to maintaining coherent, well-justified designs.
The Assumption Lifecycle:
Treat your assumption list as a living document. Update it visibly as the interview progresses. This dynamism shows you're actively thinking, not just reciting a memorized design.
Even candidates who understand assumption documentation make common mistakes. Awareness of these pitfalls helps you avoid them:
Too few documented assumptions looks careless. Too many looks like analysis paralysis. Aim for 5-10 significant assumptions for a typical interview problem. These should cover scale, consistency, latency, and the most significant technical choices.
Let's see a complete assumption documentation example for a common interview problem:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748
**POST-CLARIFICATION ASSUMPTIONS:** [A1] Scale: 10M daily active users, 1M concurrent during peak Rationale: Large-scale ride-sharing like Uber Impact: Distributed architecture required Sensitivity: HIGH - 100M would need different approach [A2] Geographic: Multi-city deployment, single region (US) for now Rationale: Confirmed with interviewer Impact: Can use single-region database, city-level sharding Sensitivity: LOW - confirmed [A3] Latency: Matching must complete < 10 seconds Rationale: User expectation for ride hailing Impact: No complex ML matching, simple proximity-based Sensitivity: MEDIUM - faster would need pre-computation [A4] Location Update: Drivers update every 5 seconds Rationale: Balance accuracy vs. system load Impact: Location data is at most 5s stale Sensitivity: MEDIUM - 1s updates would 5x the load [A5] Matching: One-to-one (one driver per rider) Rationale: Standard ride model, not pooling Impact: Simpler matching algorithm Sensitivity: LOW - can extend to pools later [A6] Consistency: Location data can be eventually consistent Rationale: Stale by seconds is acceptable for display Impact: Can use in-memory caching, async replication Sensitivity: MEDIUM - matching needs more freshness [A7] Payment: Defer payment processing details Rationale: Standard integration, not core to design Impact: Treat as external service Sensitivity: LOW - orthogonal to core system **DURING DESIGN (Added):** [A8] Driver distribution: Uniform across city Discovered: While designing matching Impact: Simple spatial indexing works If wrong: Would need demand prediction [A9] Average trip: 15 minutes, 5 miles Discovered: Capacity planning Impact: Trip storage estimates, matching turnover Sensitivity: LOW - affects sizing, not architectureNotice how assumptions A8 and A9 were added during the design phase, not upfront. This is normal and good—it shows you're actively discovering dependencies in your design.
Assumption documentation is the bridge between requirements and design. It makes your reasoning visible, enables collaboration, and protects against misalignment. Let's consolidate the key insights:
What's Next:
With assumptions documented, the final piece of requirements clarification is Confirming Understanding—the practice of validating that you and the interviewer share the same mental model before proceeding with detailed design. This confirmation step prevents wasted effort and demonstrates collaborative communication.
You now understand how to surface, document, communicate, and manage assumptions throughout a system design interview. Explicit assumptions make your reasoning visible and invite collaboration. Next, we'll learn to confirm shared understanding—the final step before detailed design.