Problem Statement: Micromobility Bike Sharing
Problem Statement: Micromobility Bike Sharing — bike sharing system design
Problem Statement: Micromobility Bike Sharing
At its core, bike sharing is a real-time inventory + locking + billing problem across two fleet models: docked (Citi Bike — bikes live in stations) and dockless (Lime — free-floating, located by GPS). Riders need trustworthy nearby availability, sub-second unlock, per-minute billing, and clear return rules.
Availability is a projection, not the truth
The key architectural stance is that availability tiles are a derived, eventually-consistent projection for the map — never the source of truth for billing or for who holds a bike. The authoritative trip and lock state lives in Trip Command; the map can be slightly stale, but a charge or an unlock decision is always made against the authoritative record.
Operational signals
Track unlock_p95_ms, availability_index_lag_sec, rebalance_tasks_open, ghost_bike_rate, trip_settlement_fail_bps. Page when unlock_p95_ms > 800 for 5 minutes or availability_index_lag_sec > 45 during commute peaks.
Failure posture
Duplicate unlock tokens must not open two trips; split-brain lock state resolves with Trip Command as writer and Lock Gateway as actuator.
1 public record TripStart(String userId, String bikeId, String idempotencyKey, Instant requestedAt) {}
1 def h3_cell(lat: float, lon: float, res: int = 9) -> str: 2 import h3 3 return h3.geo_to_h3(lat, lon, res)
1 export interface NearbyBike { bikeId: string; cell: string; batteryPct: number; lockState: "locked" | "reserved"; }
Why interviewers care
A strong answer treats this as an inventory-and-locking problem with money attached: name Trip Command as the single writer, keep availability tiles an eventually-consistent projection, and bring a real failure story (a duplicate unlock, a ghost bike) — not a generic microservice diagram.
Interview checkpoint
Keep one concrete outage ready: a flaky network makes a rider tap unlock twice, so two unlock tokens race — you prevent a double trip by making Trip Command the single writer with an idempotency key, and the Lock Gateway only actuates on its confirmed decision.
Key Highlights
- •Anchor 1-A: Trip Command owns trips
- •Anchor 1-B: H3 supply projection
- •Anchor 1-C: BLE + offline vault
- •Anchor 1-D: rebalance manifests
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Micromobility Bike Sharing, I'll separate unlock eligibility from map browse freshness."
- "Let me quantify peak unlocks/sec before picking Redis vs Postgres extensions."