Design a Scooter/Bike Sharing Platform - System Design | WinJob

Problem Statement: Dockless Micromobility Platform

Design a dockless scooter/bike sharing platform like Lime/Bird at metro scale: map discovery, QR unlock, per-minute billing, IoT telemetry, geofencing, and fleet rebalancing—not ride-hailing dispatch. This section covers problem statement: dockless micromobility platform in the understanding phase.

Operational detail

Quantify telemetry rates, unlock latency, and geofence evaluation before naming cloud SKUs. State AP for map tiles; CP for ride ledger and payment capture with explicit failure stories (Scooter shows available but battery dies mid-ride; user parks in no-park zone.).

Failure and edge cases

Scooter shows available but battery dies mid-ride; user parks in no-park zone.

Interview checkpoints

Interview note (sec-01)

When presenting Problem Statement: Dockless Micromobility Platform, tie claims to Lime/Bird operations reality—not generic ride-hailing. Mention city permit constraints and battery swap logistics where relevant.

javaOne Dark Pro

1 public record VehicleState(String vehicleId, double lat, double lon, int batteryPct, String status) {}

pythonOne Dark Pro

1 @dataclass(frozen=True)
2 class VehicleState:
3     vehicle_id: str
4     lat: float
5     lon: float
6     battery_pct: int
7     status: str

typescriptOne Dark Pro

1 export interface VehicleState {
2   vehicleId: string;
3   lat: number;
4   lon: number;
5   batteryPct: number;
6   status: 'available' | 'reserved' | 'in_ride' | 'maintenance';
7 }

Why interviewers care

a Scooter/Bike Sharing Platform interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Dockless Micromobility Platform that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Dockless ≠ docked Citi Bike—parking compliance is a first-class problem
•IoT command path (unlock/lock) is latency-critical and idempotent
•Map availability is eventually consistent; ride booking must be strongly consistent
•Rebalancing is offline optimization + field ops, not real-time matching

1	@dataclass(frozen=True)
2	class VehicleState:
3	vehicle_id: str
4	lat: float
5	lon: float
6	battery_pct: int
7	status: str

1	export interface VehicleState {
2	vehicleId: string;
3	lat: number;
4	lon: number;
5	batteryPct: number;
6	status: 'available' \| 'reserved' \| 'in_ride' \| 'maintenance';
7	}