Goal
Use this issue as a short-notice prep map for Uber-like (rides / marketplace / mobility) SDE2 system design: which topics in this repo matter most, how they connect, and where to stress-test databases and distributed queues (your stated weak areas).
It does not replace official interview guidance; it routes you to the right practice cards already tracked as issues in gardusig/interviewing.
If the interview is tomorrow (~half-day pass)
Do one vertical slice end-to-end on a whiteboard, then two depth dives (DB + queues).
-
60–90 min — core ride loop (must be fluent)
Walk: request → match → accept → trip progress → complete/cancel → payment-ish side effect. Tie together:
-
45–60 min — DB depth (your focus)
For one of the above, spell out: OLTP tables (trips, drivers, users), hot keys, indexes, read replicas vs CQRS, sharding key (e.g. city_id / driver_id tradeoffs), strong vs eventual consistency where it hurts, outbox / transactional messaging so DB commit and “emit event” do not diverge.
Practice issues: #7 Wallet / ledger, #9 Payments (idempotency keys, double-spend).
-
45–60 min — queues & distribution (your focus)
Same slice: label sync path vs async path. Practice at-least-once delivery, deduplication, DLQ, ordering (when you can’t have global order), backpressure, SQS visibility timeout pitfalls.
Practice issues: #6 SQS / messaging, #3 Notifications, #2 Analytics / logging pipeline (event bus → stream → warehouse).
-
30 min — edge & safety
#5 API gateway + rate limiting, #12 Distributed caching (cache-aside, thundering herd, TTL for ETAs).
Defer if time is tight: #10 Live streaming, #11 Offline streaming, #19 Collaborative editing — rarely the center of Uber’s core ride loop (still fine as “interesting side system” if interviewer pivots).
Uber-relevant vs secondary (issue map)
| Uber-like surface |
Practice issues |
DB angle (drill here) |
Queue / async angle |
| Core ride / trip |
#8, #14 |
Trip/driver tables, state transitions, concurrency on “accept” |
Events: TripRequested, DriverAssigned, outbox from OLTP |
| Location & maps |
#16, #18, #13 |
Geospatial structures; separating hot location writes from read paths |
Stream processing of location updates; async ETA refresh |
| Payments & ledger |
#9, #7 |
Ledger tables, invariants, reconciliation |
Async capture/settlement, idempotent consumers |
| Driver/rider comms / ops |
#17 |
Message storage, pagination, read models |
Push fanout, retries |
| Product surface (feeds, discovery) |
#15 |
Fan-out on write vs fan-out on read; ranking features store |
Async ranking / feature pipelines |
| Platform |
#5, #12, #4 |
N/A or metadata stores |
Rate limits as distributed counters; flag payloads |
Database depth checklist (what to verbalize while drawing)
- Access pattern first: who reads/writes what, QPS, p99 vs throughput.
- Keys & indexes: primary key, secondary indexes, covering indexes for “list my trips”.
- Consistency: where you need serializable / row locks vs snapshot reads; “accept ride” as compare-and-swap or conditional write.
- Scaling: sharding by region/city; cross-shard joins avoided; global entities (payments) vs local (trips).
- Reliability with messaging: transactional outbox from trip DB → queue; inbox for idempotent consumers.
- Failure: replica lag, split brain avoided by design, retry storms.
Queue & distribution checklist
- Why async: decouple peak matching from core API; absorb spikes; retry slow partners.
- Semantics: at-least-once + idempotency keys vs exactly-once (usually “effectively once” at business layer).
- Ordering: per-
trip_id partition ordering vs global ordering unnecessary.
- Poison messages: DLQ, redrive, alerting.
- SQS-shaped interview: visibility timeout, duplicate delivery, long polling; when Kafka is the better story (replay, log, many consumers).
Meta / framing
Acceptance criteria (for closing this meta issue later)
Goal
Use this issue as a short-notice prep map for Uber-like (rides / marketplace / mobility) SDE2 system design: which topics in this repo matter most, how they connect, and where to stress-test databases and distributed queues (your stated weak areas).
It does not replace official interview guidance; it routes you to the right practice cards already tracked as issues in gardusig/interviewing.
If the interview is tomorrow (~half-day pass)
Do one vertical slice end-to-end on a whiteboard, then two depth dives (DB + queues).
60–90 min — core ride loop (must be fluent)
Walk: request → match → accept → trip progress → complete/cancel → payment-ish side effect. Tie together:
45–60 min — DB depth (your focus)
For one of the above, spell out: OLTP tables (trips, drivers, users), hot keys, indexes, read replicas vs CQRS, sharding key (e.g.
city_id/driver_idtradeoffs), strong vs eventual consistency where it hurts, outbox / transactional messaging so DB commit and “emit event” do not diverge.Practice issues: #7 Wallet / ledger, #9 Payments (idempotency keys, double-spend).
45–60 min — queues & distribution (your focus)
Same slice: label sync path vs async path. Practice at-least-once delivery, deduplication, DLQ, ordering (when you can’t have global order), backpressure, SQS visibility timeout pitfalls.
Practice issues: #6 SQS / messaging, #3 Notifications, #2 Analytics / logging pipeline (event bus → stream → warehouse).
30 min — edge & safety
#5 API gateway + rate limiting, #12 Distributed caching (cache-aside, thundering herd, TTL for ETAs).
Defer if time is tight: #10 Live streaming, #11 Offline streaming, #19 Collaborative editing — rarely the center of Uber’s core ride loop (still fine as “interesting side system” if interviewer pivots).
Uber-relevant vs secondary (issue map)
TripRequested,DriverAssigned, outbox from OLTPDatabase depth checklist (what to verbalize while drawing)
Queue & distribution checklist
trip_idpartition ordering vs global ordering unnecessary.Meta / framing
Acceptance criteria (for closing this meta issue later)
system-design/README.mdor a dedicated prep doc in-repo.