Design a Real-Time Bike-Sharing System With Reservations and Live Tracking

Design a real-time bike-sharing system. Riders open an app, see available bikes near them on a map, reserve one, unlock it, ride, and end the trip by locking it, while the system keeps track of where every bike is and what state it is in.

In the interview this prompt comes from, the interviewer put heavy weight on drawing out the functional and non-functional requirements before any design, and then on trade-offs: how often bikes should report their location, where database writes become a bottleneck, and how a reserved bike is protected so that nobody else can take it.

Constraints and Clarifications

• Assume each bike has a smart lock with GPS and a cellular connection that reports location and lock state and can receive unlock commands.
• Whether bikes return to docking stations or park anywhere inside a service area is a clarifying question; say where the answer changes the design.
• Payments exist, but beyond starting and ending billing for a trip they are out of scope.

Clarifying Questions

• Docked stations, or free-floating bikes parked anywhere?
• How long does a reservation hold a bike, and may one rider hold several?
• What scale should we plan for: bikes, cities and peak concurrent trips?
• How fresh and how accurate must bike positions on the map be?

Part 1 — Requirements and core flows

State the functional and non-functional requirements and rough estimates, then outline the components, data model and APIs for finding, reserving, unlocking, riding and returning a bike.

What This Part Should Cover

• Functional scope for riders, devices and operations staff
• Consistency, latency and freshness targets per flow
• Rough load estimates for telemetry, map queries and reservations
• Core entities, bike states and API endpoints

Part 2 — Location tracking and the write path

Choose how often bikes report their location and justify it. Then design the path location updates take from the bike to the rider's map, and explain how you keep the high volume of updates from overwhelming your database.

What This Part Should Cover

• Ping-rate trade-offs between freshness, battery and data cost
• Separating high-volume telemetry from transactional state
• A geospatial index for nearby-bike queries
• Handling bikes that are offline or report out of order

Part 3 — Reservations, unlocking and contention

Two riders try to reserve the same bike within the same second. Explain how exactly one of them wins, how reservations expire, and how the unlock command and the start and end of a trip stay consistent when the bike's connection is unreliable.

What This Part Should Cover

• An atomic reservation and a comparison of locking approaches
• Reservation expiry and cleanup
• Idempotent unlock commands with timeouts and reconciliation
• Trip end and billing when the device is temporarily unreachable