System Design Simulator
Make architecture decisions step by step and see how tradeoffs evolve.
Step 1 / 5
Scenario
Uber-like ride-hailing platform
Design the core architecture for real-time ride matching, tracking, and payments.
Constraints
- •Peak city traffic spikes quickly (surge hours).
- •Location updates must feel real-time to riders and drivers.
- •Pricing and payments must remain consistent and auditable.
Pick the service boundary strategy.
Interviewer context
We are designing the ride-hailing backend with real-time tracking and payments under surge traffic. The interviewer wants to understand how you would carve services and data ownership early.
Interviewer questions
- •Which domains would you separate first (rides, tracking, pricing, payments), and why?
- •Would you start with a modular monolith or microservices given team size?
- •How would database ownership map to those boundaries?
Clarifying questions
Show interviewer tipsHide interviewer tips
- •How many teams will build/own this, and do we need independent deployments?
- •What scalability or availability pain points must be isolated early?
- •Are there legacy systems or data stores that must stay together?
Choose an approach
Guidance
Show guidanceHide guidance
What interviewers expect
- •Explain ownership boundaries and blast radius.
- •Tie the boundary choice to scale and team structure.
Scale assumptions
- •Clarify team size and deployment cadence.
- •Identify which domains change fastest.
Artifacts to outline
- •Service map with data ownership.
- •Deployment and dependency boundaries.
Failure modes to cover
- •Cross-service latency or coordination failures.
- •Shared database bottlenecks.
Architecture
Click to zoom