Back to blog

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.

Jakub MertaDec 18, 20258 min readSystem Design
#system-design#simulator#metrics#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.

Rendering diagram...

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.