Powering Crowd-sourcing of Public Transit Delays with Rust
summary
Rust services power a crowdsourced train-delay pipeline that actually runs for months without restarting, handling about 100 daily reporters, producing ~400–500 notifications per peak hour, and serving projected arrivals every 7–10 seconds. It uses tower gRPC, actix actors, Tokio timers, nats.io and Firebase, keeps route and trip state in memory with a simple HashMap, and cuts infrastructure from ~40 GB RAM to a 1 GB container. Expect processes vehicle samples every 7–10s and reduced RAM from ~40GB to <1GB.
AI-written summary · about
chapters (20)
- 0:00Intro
- 1:36Background
- 2:37Metro Trains
- 3:16Infrastructure Issues
- 5:00Data
- 6:07Solution
- 7:05Architecture
- 8:24Example
- 8:43Notify Users
- 9:08Calculate Delays
- 9:36Location Samples
- 10:16Trip Status
- 11:26Sample Processing
- 12:00Spatial Data
- 12:21Vehicle Spins
- 13:10Vehicle Spins Evolution
- 14:13Notification Service
- 15:28Actives
- 17:04Why Rust
- 19:15Questions
related talks
22m"How We Built a Rust-y Real-Time Public Transport Map"
55mScaling out operational research with Rust
46mAdopting Rust by gracefully oxidising web applications
53mBuilding Real-time Travel Alerts
42mBuilding a Web Application with Rust
35mAll aboard the Rust (electric freight) train!
38mBuilding a high performing Passenger Information System
56mThe RUST Language for High‑Load Network Services — Quick Start