Case study · Volt · Jan – Jul 2016
Ride matching, from minutes to under five seconds
Volt's inner-city ride sharing matched riders to drivers through a polling REST backend — and felt every second of it. I re-architected matching around Firebase as a client-facing view layer over the existing backend.
- Role
- iOS Developer / Tech Lead
- Where
- Istanbul
- Outcome
- Average match time cut from minutes to under 5 seconds
The problem
Matching a rider to a driver is a real-time problem, but the system underneath was request/response: the iOS app polled a Django REST API every few seconds asking “anything yet?”. Under real load, the average match took minutes — an eternity when you’re standing on a curb watching a spinner.
The instinct would be to rewrite the backend. With a small team and a live product, that wasn’t an option.
The insight
The backend didn’t need replacing — the delivery path did. I kept the Django matching engine as the source of truth and introduced Firebase Realtime Database as a client-facing view layer: the backend writes match state into Firebase, and Firebase pushes it to the apps the moment it changes. No polling loop, no request overhead, no “anything yet?”.
It’s the same shape as CQRS — the write model stayed put while reads became push-based — applied with a pragmatic, managed tool instead of new infrastructure to operate.
What I did
- Designed the view-layer architecture and the data model for match state in Firebase.
- Rebuilt the iOS matching flow in Objective-C around real-time listeners.
- Mentored the backend and Android developers through their sides of the integration — my first tech-lead role.
Outcome
Average match time dropped from minutes to under five seconds. The product finally felt like what it was: live.