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. ```hint Split by actor List what riders, the bikes themselves and the operations team each need from the system; their non-functional needs differ sharply. ``` #### 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. ```hint Not every ping is equal A parked bike and a bike in the middle of a trip do not need the same reporting rate, and the map does not need every update stored the same way. ``` #### 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. ```hint One source of truth Decide which store owns a bike's state, and make the change from available to reserved a single conditional step there. ``` #### 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 ### What a Strong Answer Covers - Requirements gathered first and used to justify later trade-offs - Telemetry kept off the transactional database's hot path - A reservation mechanism that is correct under concurrency without a fragile external lock - Device communication designed for lost messages, duplicates and timeouts - Partitioning by geography and clear observability of unlock success and map freshness ### Follow-up Questions - A bike loses connectivity mid-ride. How do you end the trip and bill it fairly? - How would you detect a bike being moved when no trip is active? - How would you decide where to rebalance bikes from crowded areas to empty ones? - How would the design change for electric scooters that report battery levels and need charging?