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.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
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
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
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 ask about
- 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 (L5/E5)
- 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 (L6+/E6+)
- 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.