Ride-Hailing ETA & Routing System Architecture Questions

System design and architecture questions modeled on large-scale ride-hailing and on-demand mobility platforms: how a production-grade ETA (estimated time of arrival) and routing system is built and scaled. Covers real-time driver and GPS telemetry ingestion, map-matching (point-to-segment snapping, Hidden Markov Model approaches), road-graph representation and geospatial indexing (H3, S2, quadtrees), routing algorithms (Dijkstra, A*, contraction hierarchies) versus ETA prediction models, live traffic-data integration, caching and API contract design, multi-region and geo-distributed deployment, fault tolerance, and data consistency trade-offs at rideshare scale. Questions reason about the general system-design problem faced by this class of platform, not any single company's non-public internal implementation.

EasyTechnical

70 practiced

Explain load balancing strategies relevant to an ETA platform: global traffic distribution (DNS, anycast), regional edge POPs, local LB (L4 vs L7), and client-side routing. For each, state SRE actions to detect and react to unhealthy backends or network partitions.

HardSystem Design

68 practiced

Design an architecture for near-real-time simulation of city-wide routing under hypothetical incidents (e.g., road closures) to estimate ETA impacts and recommend mitigations. Discuss data inputs, compute model fidelity vs speed trade-offs, how to parallelize simulations, and how to integrate results into operations dashboards.

Sample Answer

Requirements & constraints:- Functional: ingest live traffic + static map, run many what-if incidents (road closures, lane reductions) and estimate ETA deltas and mitigation recommendations within near-real-time (target: 30–120s per event batch).- Non-functional: tolerate high throughput, predictable latency, multi-tenant isolation, reproducibility, auditability, and SLOs (e.g., 95% results within 60s).

High-level architecture:- Ingest layer: Kafka topics for telemetry (GPS pings, speeds, incidents), event bus for operator-triggered hypothetical incidents, and batch loader for static map/OD matrices.- Preprocessing: Stream processors (Flink/Beam) that fuse telemetry into link-level speeds, detect anomalies, and emit time-windowed traffic state snapshots to a fast store (Redis/TimescaleDB).- Simulation engine pool: Containerized worker pool (Kubernetes) running lightweight microsimulators. A coordinator (service) schedules jobs, shards city graph, and aggregates results.- Storage & caching: Tile-based cached traffic state in Redis for sub-second access; object store (S3) for archived run artifacts.- Orchestration: Job queue (Celery/Kafka + Argo Workflows) + autoscaler that scales workers by queue depth and CPU.- API & Dashboard: REST/gRPC API for queries; results pushed to dashboard via WebSocket; Grafana for ops metrics and Kibana for logs.- Observability & Reliability: Prometheus metrics, structured logs, distributed tracing, alerting on latency/SLA breaches, canary deploys and feature flags.

Data inputs:- Static: road graph, speed limits, turn restrictions, link capacities.- Dynamic: aggregated link speeds, traffic signals/timing, public transport schedules, scheduled events.- Demand: OD matrices (historical + real-time adjustments from telemetry).- Incident spec: location, closure extent, duration, severity.

Model fidelity vs speed trade-offs:- Fidelity options: - Macroscopic (flow-based): coarse but fast; good for city-wide ETA deltas. Use for initial estimates. - Mesoscopic: per-vehicle aggregated behavior; balanced accuracy/latency. - Microscopic (agent-based): high fidelity, expensive; used sparingly for critical corridors.- Strategy: multi-tier approach — run a fast macroscopic simulation to filter scenarios, then selectively run higher-fidelity simulations on top-N impacted areas. Cache intermediate results and reuse traffic snapshots to avoid recomputing base state.

Parallelization strategy:- Spatial sharding: partition city graph into overlapping tiles to run simulations concurrently; handle border interactions via ghost regions and iterative boundary exchange.- Scenario-level parallelism: each hypothetical incident is an independent job; multi-tenant scheduling across worker pool.- Time-slicing: forecast windows processed in parallel where independent (e.g., non-overlapping time horizons).- Worker design: stateless containers that load cached base snapshot and local graph shard, run simulation, and emit delta metrics. Use SIMD/vectorized numerical kernels or GPU acceleration for meso/micro models where beneficial.- Aggregation: reduce step merges shard outputs, resolves border conflicts with a deterministic reconciliation policy to ensure reproducibility.

Operational considerations:- Autoscaling: HPA on queue length/latency; pre-warm pools for traffic spikes (rush hour).- SLOs & throttling: enforce per-customer/operation rate limits; degrade gracefully (return macroscopic estimate with confidence intervals when under load).- QA & validation: shadow simulations against historical incidents; track model drift and retrain calibration parameters.- Resilience: retries with backoff, circuit breakers, job checkpointing to resume long runs, and graceful degradation to cached snapshots.

Integrating results into operations dashboards:- API emits structured results: ETA deltas by OD pairs, percentiles, affected corridors, recommended mitigations (alternate routes, signal retiming, contraflow).- Dashboard components: - Map overlay: heatmap of ETA impact; clickable corridors showing time series. - Scenario panel: parameters, confidence scores, recommended actions with estimated benefit and cost. - Compare mode: baseline vs scenario and multi-scenario comparison. - Alerts & playbooks: generate alert cards with automated runbooks, suggested mitigations, and start buttons to push recommended configuration to traffic control systems (with approval workflow).- UX performance: stream incremental updates via WebSockets; compress payloads; paginate large OD result sets.- Audit & compliance: persist scenario inputs + outputs with versioning for post-incident reviews.

Example mitigation pipeline:1. Operator triggers "closure on Main St".2. Fast macroscopic run (10s) flags 15% ETA increase on downtown.3. System schedules mesoscopic runs for top-3 corridors (60s).4. Dashboard shows recommended mitigations (reroute X & Y, adjust signals by +10s) with predicted 70% ETA recovery. Operator approves; system triggers playbook to apply changes via traffic-control API; all actions logged and monitored.

This design balances speed and accuracy using tiered fidelity, parallelism across scenarios and space, strong observability, autoscaling, throttling, and clear integration into operational workflows so SREs can ensure reliable, timely, and actionable what-if simulations.

EasyTechnical

131 practiced

Define what ETA (Estimated Time of Arrival) means in the context of a ride‑hailing platform. List all typical inputs and external data sources (e.g., driver GPS, map tiles, traffic provider), units and frequency for each input, and describe the SRE concerns when operating an ETA service (latency budgets, monitoring signals, validation of accuracy).

Sample Answer

ETA (Estimated Time of Arrival) is the predicted time until a driver reaches a target location (pickup or drop‑off) given current state — usually expressed as either a duration (seconds/minutes) or an absolute timestamp.

Typical inputs & external data sources (units and suggested frequency):- Driver GPS: lat/lon, speed, heading, accuracy (meters). Frequency: 1–5s for active trips; 10–30s idle.- Driver vehicle telemetry: speed, odometer, status (en route/paused). Units: km/h or m/s, boolean status. Frequency: 1–10s.- Rider location: lat/lon, desired pickup point. Frequency: on change or every 5–15s while searching.- Map routing graph / tiles: road segments, speeds, turn restrictions. Units: meters, segment IDs. Refresh: daily/weekly; tiles cached locally.- Live traffic provider: travel time multipliers or segment speeds. Units: km/h or multiplier. Frequency: 30s–5min.- Historical/ML travel time models: per-segment expected times by time-of-day. Units: seconds. Updated: hourly–daily.- Road events / incidents feed: accidents, closures. Units: event metadata; pushed as events (real-time).- Weather feed: precipitation, visibility (affects speed). Frequency: 5–15min.- Surge/pricing & business rules: affects routing priorities. Frequency: change-driven.

SRE concerns when operating ETA service:- Latency budgets: tight p95/p99 compute target (e.g., p95 < 100ms for API response; p99 < 500ms) to avoid UI lag. Include network, model inference, and routing lookups.- Availability & scaling: horizontally scalable routing and model services; autoscaling for surges; circuit breakers if downstream (traffic provider) fails.- Monitoring signals: request latency histograms, error rates, timeouts, cache hit ratio (map/tiles), freshness metrics for inputs (staleness of GPS, traffic feed age), model drift indicators, p95/p99 ETA error vs actual arrival (accuracy), queue lengths.- Alerts & SLOs: SLOs for API availability (e.g., 99.9%), latency SLOs, and accuracy SLO (median ETA error < X seconds). Alert on input staleness or sudden accuracy degradation.- Validation of accuracy: continuous evaluation pipeline computing real-time error metrics (ETA vs actual arrival), segmentation by city/time/driver, automated A/B tests for model changes, canary rollouts, and guardrails (fallback to conservative heuristics if model outputs are implausible).- Observability & debugging: distributed tracing across GPS ingestion → routing/model → API; logs with sample requests/inputs for repro; dashboards for per-region accuracy and input freshness.- Resilience: graceful degradation—if traffic provider fails, fall back to historical averages; rate limit noncritical features; cache previous ETAs temporarily.- Security & privacy: protect location data in transit and at rest; minimize retention.

These practices ensure ETA is timely, accurate, and observable while keeping the service resilient under load and external failures.

MediumTechnical

80 practiced

Describe a capacity planning exercise for an ETA service before a large city event (e.g., concert). What metrics and historical signals do you analyze, how do you simulate expected load, and what preemptive operational actions would you take?

Sample Answer

Situation: A huge concert in the city in two weeks will drive concentrated ETA requests and map/route computations. As the SRE responsible for ETA service capacity, I’d run a short exercise to ensure SLOs hold during the surge.

Metrics & historical signals to analyze- Traffic: peak RPS, requests/minute, concurrent connections, request type breakdown (ETA vs. booking vs. map tiles).- Latency & error: p50/p90/p99 latencies, 5xx/4xx rates, time-to-first-byte.- Downstream: DB QPS, cache hit rate, external routing API latency/limits.- Resource: CPU, memory, network I/O, file descriptors, thread pool saturation.- Historical signals: prior event spikes (similar concerts, sports), day-of-week/time patterns, weather data, transit closures, and marketing campaigns.- Business KPIs: acceptable ETA error/slack, customer-impact thresholds tied to SLOs.

Simulating expected load- Build scenarios: baseline + 2x, 3x, and worst-case (traffic spike concentrated in ±30 minutes of event end). Use historical multipliers (e.g., past concert saw 2.8× baseline).- Replay traffic with realistic request mixes (including heavy route computation and map-tile fetches) using load tools (k6 or JMeter) from distributed locations to simulate geo-concentration.- Inject downstream latencies and partial failures (DB slow, cache miss surge, external API throttling) to test graceful degradation.- Run soak tests for the expected surge window plus ramp-up/down to check autoscaling and stateful component behavior.

Capacity calculations- Translate target p99 latency and error budget into required CPU/memory/connection capacity. E.g., if one app pod handles 150 RPS at p99 target, need ceil(peakRPS/150) pods + 20–30% buffer for burst and autoscaler lag.- Account for database connection pools and cache throughput—scale read replicas or cache nodes accordingly.

Preemptive operational actions- Infrastructure: - Pre-scale (warm pods/nodes) to calculated baseline + buffer timed before event (avoid cold autoscaling). - Increase autoscaler limits and tune cooldowns to react faster. - Ensure horizontal and vertical headroom in DB and cache; add read replicas or sharding if needed.- Software/config: - Deploy a tested canary release that includes performance improvements or telemetry. - Enable degraded mode for non-critical features (reduced map detail, batch non-urgent analytics). - Bump rate limits for internal components; implement priority queues for high-value requests. - Cache priming: pre-warm caches for hot origins/areas around the venue.- Observability & runbooks: - Create dashboards for key metrics and alert thresholds tied to SLO burn rates. - Prepare runbooks for common failure modes (DB saturation, external API throttling, autoscaler failures). - Schedule increased on-call staffing and an incident commander for event window; run a tabletop drill.- External coordination: - Throttle or queue non-essential downstream consumers (analytics, batch jobs) during surge window. - Coordinate with traffic/marketing teams about possible mitigations (staged notifications).- Post-event: - Collect telemetry, run postmortem comparing simulated vs. actual, update models and capacity plans.

Why this works- Uses data-driven historical multipliers and realistic mixes to size capacity.- Tests not just throughput but failure modes and downstream behavior.- Pre-scaling plus tuned autoscaling and operational readiness minimizes user impact while controlling costs.

MediumTechnical

84 practiced

Describe a safe canary strategy for deploying a new routing model that alters ETA outputs. Include traffic split schedule, health metrics to monitor, automated rollback criteria, and how to use shadow traffic and feature flags to reduce risk.

Sample Answer

Situation: We need to deploy a new routing model that changes ETA outputs while minimizing user impact and preserving SLOs.

Canary plan (traffic split schedule):- Day 0: Internal + dark/QA traffic only.- Phase 1 (0–2 hours): 0.5% production traffic.- Phase 2 (2–6 hours): 2% if Phase 1 healthy.- Phase 3 (6–24 hours): 10% if Phase 2 healthy.- Phase 4 (24–72 hours): 30% then 60% then 100% as metrics remain stable.- Each step advances automatically only when health checks pass for a rolling window (e.g., 30 min) and manual gate available.

Health metrics to monitor:- Business/UX: ETA error distribution (median, 90th, 99th), proportion of >X-minute ETA regressions, cancellation rate, completion rate.- System: request latency (p95/p99), CPU/memory, model inference error rates, request queue length, downstream service error rates.- SLOs: request success rate, user-facing latency SLOs, error budget consumption.

Automated rollback criteria:- Immediate rollback triggers: - Spike in user errors or 5xx rate > baseline + 0.5% absolute within 5 minutes. - Latency p99 > baseline * 1.5 sustained for 10 minutes. - ETA regressions: >3% increase in proportion of excessive ETA misses or increase in cancellations >2% absolute. - Error budget burn rate exceeds threshold.- Rollback action: Traffic routed back to previous model; alert on-call; create incident with diagnostic dumps.

Shadow traffic & feature flags:- Shadow traffic: send full copy of production requests to new model asynchronously to compare predictions without affecting users. Collect metrics (ETA diffs, inference time) and run offline validators to detect distributional drift.- Feature flags: gate model by flag with targeting (by region, user cohort, device). Use flags to quickly scale canary up/down per cohort. Keep flag controls in config service with audit logs and automated playbooks.

Operational practices:- Health-check automation + circuit breaker in edge proxy.- Run A/B metrics pipelines and statistical tests (e.g., sequential testing with false-positive control).- Post-deploy: run 48–72 hour postmortem and promote only after regression-free window.This approach balances safety (shadowing + small steps + feature flags) with automation to minimize human delay while preserving reliability.

Unlock Full Question Bank

Get access to hundreds of Ride-Hailing ETA & Routing System Architecture interview questions and detailed answers.

Join thousands of developers preparing for their dream job.