System Design Simulator: Uber-like Architecture Walkthrough
A behind-the-scenes look at the new System Design Simulator: how decisions shape the diagram, metrics, and tradeoffs.
Summary
How the simulator turns choices into metrics, feedback, and a realistic architecture narrative.
Key takeaways
- Every decision updates the same shared metric model.
- Tradeoffs are displayed at the step level and in the final summary.
- Diagram updates reflect architectural consequences, not just visuals.
- Scoring is meant to teach, not to judge.
System Design Simulator: Uber-like Architecture Walkthrough
The System Design Simulator is a multi-step experience that mirrors real interview discussions: you make architectural choices, the diagram evolves, and the result matrix shows the tradeoffs you introduced. There are no perfect answers—only different paths with different consequences.
The scenario
We start with an Uber-like ride-hailing platform: real-time location updates, matching at scale, and high reliability during surge traffic.
Baseline architecture
The simulator renders a base diagram and then extends it after each decision.
As you progress, your choices add new components like queues, caches, or event buses.
How the simulator works
Each step presents multiple options. For example:
- Modular monolith vs. service‑oriented vs. event‑driven core
- Redis Geo vs. PostGIS vs. Cassandra for location storage
- WebSockets vs. SSE vs. polling for real‑time updates
Signals and tradeoffs
Every answer nudges five signals: latency, cost, reliability, complexity, and scalability. Scores are additive, and higher is better. The intent is to expose tradeoffs instead of pretending there is a single “correct” architecture.
“Why” behind each delta
Each choice includes a short explanation for every metric it changes. For example:
- WebSockets improves latency because it keeps persistent connections.
- It may reduce the cost score because many open connections increase infra overhead.
- It can increase complexity due to stateful gateway management.
The simulator surfaces these reasons in the final matrix so you can see exactly why the system moved in a given direction.
Influences between steps
Some early choices affect later ones. For instance:
- Choosing microservices increases coordination cost for WebSockets.
- An event bus reduces the incremental complexity of adding a queue.
This is closer to how real system design works: later improvements can partially offset earlier tradeoffs, and the output reflects those interactions.
What you see at the end
The result matrix includes:
- Strengths and risks for each step you chose
- Tradeoffs in plain language
- Why signals moved (the per-metric explanation)
- Influences caused by earlier decisions
Try it
The System Design Simulator is now live on the landing page. Use it to explore how small architectural changes compound into different outcomes—and bring those insights to your next interview.
Read next
View allSystem Design Interview: From Zero to Hero
Learn how to approach complex system design problems and communicate your architecture decisions effectively.
Building the System Design Simulator with Codex CLI
An end-to-end account of building the System Design Simulator with Codex CLI, covering data modeling, diagrams, scoring, and feedback.
Building a Real-Time Canvas Demo: Load Balancer Flow
A practical Canvas API showcase that visualizes a load balancer distributing traffic to app servers.