Scaling out operational research with Rust
summary
Rust code replaces orchestration around an existing C++ optimizer to run vehicle routing at production scale: a Rust runner out-of-process spawns split subproblems, merges partial solutions, and keeps the original Java API unchanged. The system handles about 220,000 requests/day (~800,000 computations), including tiny jobs solved in milliseconds and huge ones (20k services, hundreds of vehicles) previously taking 2.5 hours now reduced by splitting to ~12–13 minutes. Operates on Kubernetes + Redis + S3, delivers hundreds of computations per second, and works in production with minor Rust pain points (Tokio lifetimes, CI caching, Redis tuning).
AI-written summary · about
chapters (17)
- 0:00Introduction
- 3:58Company history
- 10:01Legacy C++ challenges
- 11:48Why Rust for scaling
- 14:13Rust runner design
- 17:03Scaling up vs out
- 20:37Algorithm service architecture
- 24:27Kubernetes deployment challenges
- 26:36Handling latency spikes
- 28:01Rust preprocessing
- 30:14Future algorithm plans
- 33:01Rust in production
- 36:15Rust strengths and pain points
- 41:32Rust for operational research
- 42:13Building trust in Rust
- 45:23Healthy workplace importance
- 46:00Q&A
related talks
29mLessons Learned: Porting a Streaming Data Pipeline from Scala to Rust.
28mPowering Crowd-sourcing of Public Transit Delays with Rust
46mAdopting Rust by gracefully oxidising web applications
22m"How We Built a Rust-y Real-Time Public Transport Map"
20m"Rust in Motion: Building Reliable and Performant Robotics Systems"
20mMastering Rust on Edge and Cloud — AI/IoT Case Studies
27mDeterministic fleet management for autonomous mobile robots using Rust
35mAll aboard the Rust (electric freight) train!
