Problem Statement: Dockless E-Scooter Rental
Problem Statement: Dockless E-Scooter Rental — e-scooter platform interview depth
Problem Statement: Dockless E-Scooter Rental
Phase understanding — Design a dockless e-scooter rental platform (Bird / Lime / Spin class) where riders discover nearby vehicles, unlock via QR or BLE, ride with live GPS billing, and park inside geofenced zones. Unlike ride-hailing, there is no human driver—the fleet is IoT-connected hardware with battery, lock, and motor controllers. Interviewers expect you to separate rider UX latency (unlock under 3s) from telemetry firehose (GPS every 2–5s per vehicle). State fleet scale early: e.g., 40 cities × 3k scooters ≈ 120k connected devices.
How the pieces fit
The rider app talks to an API Gateway fronting the Trip/Command service (the single writer for trip and lock state). A Fleet Registry holds each scooter's authoritative state (battery, lock, firmware, last-seen), fed by the MQTT telemetry stream. Postgres backs the transactional trip and billing data; the telemetry firehose lands in a time-series store. The unlock path stays short and synchronous; everything telemetry is async.
Operations
Runbook for problem: page when unlock_success_rate drops below 98% for 5 minutes or MQTT consumer lag exceeds 30s.
Failure posture
Never leave vehicle in RESERVED without TTL; never bill without SETTLING receipt row.
The invariants
State the invariants before any cloud SKUs: a scooter is never left RESERVED without a TTL, a trip is never billed without a settled receipt row, and the unlock decision is always made by the single command writer, not the telemetry projection.
1 public record ScooterSlice(String vehicleId, String idempotencyKey) {}
1 def problem_health_metric() -> str: 2 return "problem_ok"
1 export interface TelemetryPoint { vehicleId: string; lat: number; lng: number; }
What to nail here
Lead with concrete numbers (120k connected devices, GPS every 2-5s, unlock under 3s) and the clean split between the synchronous unlock path and the asynchronous telemetry firehose — that framing, not a generic microservices diagram, is what signals you understand the IoT-fleet shape.
Why interviewers care
A strong answer treats this as an IoT-fleet command-and-billing problem: separate the sub-3s unlock path from the telemetry firehose, name the single command writer, and bring a real failure story (a scooter stuck reserved, a double-billed trip) — not a generic microservice diagram.
Interview checkpoint
Keep one concrete outage ready: a scooter's MQTT link drops mid-trip, so GPS billing stalls — you cap the fare at last-known-good, mark the trip for reconciliation when the device reconnects, and never charge the rider for phantom distance.
Key Highlights
- •Rider App
- •API Gateway
- •Fleet Registry
- •Postgres
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Dockless E-Scooter Rental, I'll separate telemetry ingest from unlock API scaling."
- "Let me state vehicle state machine before picking MQTT vs HTTP."