Design a Long-Distance Bus Ticketing Platform

Medium45 min
1 / 30
understanding9 min read

Problem Statement: Long-Distance Bus Marketplace

Problem Statement: Long-Distance Bus Marketplace — bus ticketing interview depth

Problem Statement: Long-Distance Bus Marketplace

Design a RedBus / FlixBus / Wanderu-class bus marketplace: multi-operator aggregation, interactive seat maps, dynamic pricing, festival surge fairness, operator webhooks, and QR boarding passes. This section covers problem statement: long-distance bus marketplace in the understanding phase.

Operational detail

Assume 40M registered travelers, 1.2M bookings/day, ~18K concurrent departures, festival windows up to 45K bookings/min on ~200 hot trips. Search averages ~3.5K RPS with 12× morning peak; holds expire in 8 minutes. Hot seat counts live in Redis shards keyed by trip_id, authoritative bookings in PostgreSQL with optimistic inventory_version. Operator GPS ingest ~900 events/s when enabled. CAP: CP for confirmed seats, AP for search ranking with price_as_of timestamps.

Failure and edge cases

  • Double booking without version check → 409 INVENTORY_STALE
  • Festival thundering herd → per-user token bucket + trip-scoped queue
  • Operator webhook delay → booking stays PENDING_OPERATOR with visible SLA
  • Stale seat map UI → ETag on layout blob; server rejects unknown seat_ids
  • PSP success but operator reject → saga issues auto-refund + releases seats

Interview checkpoints

javaOne Dark Pro
1public record HoldToken(String tripId, int inventoryVersion, Instant expiresAt) {}
pythonOne Dark Pro
1def stop_ranges_overlap(a_from: int, a_to: int, b_from: int, b_to: int) -> bool:
2 return max(a_from, b_from) < min(a_to, b_to) # order 1
typescriptOne Dark Pro
1export interface Booking { id: string; tripId: string; seats: SeatLease[]; state: "HELD" | "CONFIRMED"; }
2export function holdKey(tripId: string): string { return `hold:${tripId}`; }

Numbers to say aloud

  • Festival: 45K bookings/min ≈ 750 holds/s on narrow trip shards — size pools before debating Kafka.
  • Stop-pair index precomputed per trip; allocator is O(log n) shard lookup, not full scan.
  • Live bus ETA: p95 error < 120s when GPS fresh; schedule-only band when ping age > 90s.

Why interviewers care

a Long-Distance Bus Ticketing Platform interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Long-Distance Bus Marketplace that proves you understand real outages, not happy-path diagrams.

Key Highlights

  • focus for sec-01
  • CP inventory vs AP search cache
  • Quantify festival shard load before queues
Interview tip
Mention Festival surge opens as a timed quota window with queue fairness, no when discussing Problem Statement: bus ticketing & Live ETA.
Avoid
Treating trains like flights without segment overlap or Festival surge queue fairness.

Section Rescue Kit

Buzzwords to use:

BookingRefFestival surge

Safe statements:

  • "For Problem Statement: bus ticketing & Live ETA, I separate CP seat ledger from AP live train position."
  • "I quantify Festival surge RPS before naming Kafka vs SQS."
Design a Long-Distance Bus Ticketing Platform - System Design | WinJob | WinJob