# Design a bike sharing system: system design interview question

> Bike discovery and ride control must reflect physical locks despite stale locations and device outages.

Source: https://sysround.com/questions/design-bike-sharing-system
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a bike sharing platform. Riders use it to find, unlock, and return bikes. Bikes can lose their network connection."

## What to clarify first

- Fleet and ride volume
- Read and write traffic
- Bike hardware
- Device connections
- Latency
- Map freshness
- Consistency and availability
- Return rules
- Durability and retention
- Scope limits

## Scope of a strong answer

Core requirements:

- Find nearby bikes that appear available
- Unlock a bike without assigning it to two rides
- Track the ride and show uncertain outcomes
- Confirm a return from physical lock evidence

Usually out of scope:

- Payments and pricing
- Fleet repair and bike transport
- Reservations before the rider reaches the bike
- Unlocks without a phone network connection

## What interviewers probe

### Nearby discovery

A nearby result combines location, freshness, and ride state. Device outages make each fact uncertain at a different time.

### Ride lifecycle

The database cannot commit a transaction with a physical lock. A lost reply can hide a successful unlock.

### Returns during device outages

A physical return can precede server confirmation by many minutes. Late evidence must end the correct ride without changing a newer ride.

## Common mistakes

- The design treats a sent command as proof that the lock opened.
- The design releases an expired attempt while an old command can still open the bike.
- The design treats the map index as the authority for ride assignment.
- The design trusts a phone report as proof of a physical return.
- The design uses message arrival order as the order of physical events.
- The design gives telemetry and ride events equal priority after a device outage.

## The bar by level

- **Senior:** Defines the command protocol across server and device failures. Handles repeated requests, command expiry, late events, and durable return evidence. Separates approximate map state from authoritative ride state.
- **Staff+:** States the hardware guarantees that the protocol needs. Explains safe recovery when evidence is incomplete. Defines safe authority transfer during failover. Separates telemetry load from ride control.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=bike-sharing


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.