Design Public Transit App - System Design | WinJob

Problem Statement: Public Transit App

Phase understanding — Consumer multimodal app (Transit/Moovit class): plan A→B across bus/subway/ferry, show live boards, surface delays, and push alerts. Contrast with operator-only AVL dashboards. Unique checkpoint 1: problem statement: public transit app drives interview narrative for design-transit-app.

Mechanism

Transit apps combine offline-capable static schedules with streaming GTFS-RT. The planner optimizes generalized travel time; the realtime layer only adjusts departures on chosen legs. Keep graph versioning explicit: static bundle effective_date gates routing, while RT overlays reference trip_id + stop_sequence.

Operational metrics

Track planner_p95_ms, rt_ingest_lag_sec, arrival_error_p95_sec, and push_delivery_p95_sec. Page when RT lag > 120s for any tier-1 agency during rush hour. Cap WS fanout per stop to prevent thundering herd when a subway line pauses.

Edge cases

Missing stop_times.txt for detour day → fall back to prior bundle with banner.
User plans during DST jump → anchor timezone on agency feed, not device offset alone.
Broken pedestrian edge after construction → graph patch pipeline within 24h.
Alert polygon overlaps duplicate routes → dedupe notifications per user per 10 minutes.

Interview checkpoints

Say aloud why trip planning and AVL dashboards are different products.
Quantify plan QPS before naming Kubernetes.
Show confidence bands on ETAs instead of fake precision.

javaOne Dark Pro

1 public record ItineraryRequest(String fromPlaceId, String toPlaceId, Instant departAt, boolean wheelchair) {}

pythonOne Dark Pro

1 def confidence_band(ping_age_sec: float) -> str:
2     if ping_age_sec < 30:
3         return "LIVE"
4     if ping_age_sec < 120:
5         return "DELAYED"
6     return "SCHEDULE"

typescriptOne Dark Pro

1 export interface ArrivalSnapshot { stopId: string; tripId: string; etaSec: number; confidence: "LIVE" | "SCHEDULE" | "STALE"; }

Why interviewers care

Public Transit App interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Public Transit App that proves you understand real outages, not happy-path diagrams.

Key Highlights

•Consumer multimodal app (Transit/Moovit class): plan A→B across bus/subway/ferry, show live boards, surface delays, and push alerts.
•Phase understanding checkpoint 1
•GTFS static + GTFS-RT boundary explicit

1	def confidence_band(ping_age_sec: float) -> str:
2	if ping_age_sec < 30:
3	return "LIVE"
4	if ping_age_sec < 120:
5	return "DELAYED"
6	return "SCHEDULE"