Practice Scenarios Generator
The Interview Simulator
Click the button below to generate a random System Design problem. But wait—real life isn’t that simple. Once you have your problem, click “Reveal Constraints” to see the hidden requirements that would trip you up in a real interview.
</div>
• Geo-Replication
• Hotspot Mitigation
• Failover Modes
• Correctness checks
• Ring Buffers
• Custom Protocols
Justify trade-offs between these paths using constraints.
Whiteboard Management
Designing a system is 50% technical and 50% presentation. A messy whiteboard suggests a messy mind.
The 4-Quadrant Layout
Divide your whiteboard (or Excalidraw canvas) into 4 clear zones. This helps you and the interviewer keep track of the discussion.
• Non-Functional
• QPS / Storage Calc
• The "Big Picture"
• Data Flow Arrows
• JSON Objects
• Table Schemas
• Caching Strategy
• Algorithms
| Zone | Content | Purpose |
|---|---|---|
| 1. Requirements | North Star | Keep QPS and Core Features visible so you don’t lose focus. |
| 2. Architecture | The Map | The main visual (represented as “The HLD Map” in our roadmap). |
| 3. Data/API | The Contract | Define how data moves. |
| 4. Deep Dives | Strategic Path | Use this to branch into the Scale, Reliability, or Performance paths shown in our roadmap. |
[!TIP] Don’t Erase History. Instead of erasing your High-Level Design to draw the Deep Dive, try to keep the HLD visible and draw a “Zoom In” box for the detailed component in Zone 4.
Sample Whiteboard Layouts
Here are two examples of how to organize your whiteboard for common system design problems. Notice how the 4-quadrant structure keeps the information dense but readable.
Example 1: Design Twitter (News Feed)
Example 2: Design a URL Shortener
The First Principles Approach
What happens when you get a question you’ve never seen before?
- “Design a system to count the number of cigarettes smoked in Paris in real-time.”
- “Design a control system for a nuclear reactor.”
Don’t panic. Fall back on First Principles.
- Inputs & Outputs: Where does data come from (Sensors? Users?) and where does it go (Dashboard? Alert?).
- Volume & Velocity: Is it a firehose (1M events/sec) or a drip (1 event/hour)?
- High Velocity -> Branch into the Performance Path (Zero-GC, Ring Buffers).
- High Volume -> Branch into the Scale Path (Sharding, Geo-Replication).
- Low Velocity -> REST API and SQL DB.
- Storage: Do we need to keep it forever?
- Yes -> S3 / Data Lake.
- No -> Redis (TTL).
- Bottlenecks: Where will it break?
- DB is slow -> Add Cache.
- Server is slow -> Add Load Balancer.
- Network is slow -> Add CDN.
Useful References
Interactive Architecture Board
Practice your High-Level Design by dragging and dropping components onto the canvas. Draw lines to connect them.