All Challenges
MediumRideShare · Part 1

RideShare 1 - City Launch

DatabasesAPI DesignLoad BalancingWebSockets
Solve in Design Lab →

Problem Statement

ZipRide is a new ride-hailing startup launching in a single city (population ~2 million). The app needs to:

•Let riders request a ride and see nearby available drivers in real time.•Match riders with the closest available driver within 15 seconds.•Track the driver's location on a map during the ride (updates every 3 seconds).•Handle payment processing at ride completion.

The founding team has 4 engineers and a moderate cloud budget. They expect 50,000 rides per day within the first 6 months.

What You'll Learn

Launch a ride-hailing app in a single city with real-time driver matching. Build this architecture under realistic production constraints, then validate tradeoffs in the design lab simulation.

DatabasesAPI DesignLoad BalancingWebSockets

Constraints

Active drivers (concurrent)~3,000
Daily rides~50,000
Match time< 15 seconds
Location update frequencyEvery 3 seconds
City radius~30 km
Availability target99.9%
ApproachClick to expand

How to Approach

Clarify requirements: MVP rideshare -- rider requests a ride, driver accepts, they are matched, fare calculated, payment taken. Core entities: riders, drivers, trips.

Estimate scale: ~50k rides/day, ~3k concurrent drivers updating location every 3 seconds. Simple architecture with the right data stores is sufficient.

Pick components:

  • •Mobile clients (rider + driver apps) hit an API server
  • •SQL DB for trips, users, payments (structured, relational data)
  • •NoSQL for driver locations (high-frequency writes, key-value: driver_id -> {lat, lng, status})
  • •Simple matching: query nearby available drivers on trip request

Key tradeoffs to discuss:

  • •Location data is write-heavy (every driver updates every 3s) -- do not put it in SQL
  • •Trip state machine: requested -> accepted -> in_progress -> completed -> paid
  • •Payment: pre-authorize on request, capture on completion
  • •Why not microservices yet? At this scale, a monolith is simpler and easier to operate

Learn the Concept

Databases Topic HubAPI Design Topic HubLoad Balancing Topic HubWebSockets Topic Hub

Related guided labs:

Database Replication & Read ScalingNoSQL & Document DatabasesSchema Design Workshop

Practice Next

Reference SolutionClick to reveal

MVP rideshare: mobile apps talk to a monolithic API server. PostgreSQL stores structured data (trips, users, payments). A fast key-value store stores driver locations separately since they update every 3 seconds -- SQL cannot handle that write rate efficiently. A session cache speeds up auth lookups. Keep it simple at this scale.

Solve in Design Lab →Next: RideShare 2 →