Scaling a Ride-Booking Platform Toward 25K Daily Rides

When we started on the dispatch backend, the platform was handling 1,000–1,500 rides a day. The brief was simple to say and harder to do: get the architecture ready for 20K–25K daily rides without a rewrite.

The first bottleneck wasn't the database — it was synchronous work sitting in the request path. Every booking touched pricing, driver matching, notifications, and reporting inline. We moved all of that off the request thread into queue jobs, so a booking request returns in milliseconds and the rest happens in the background.

Redis did two jobs at once: it backed our queues, and it cached the pieces of state that were being read far more than they were written — driver locations, live trip status, surge pricing snapshots. That single change removed a large share of repeated database load.

For real-time updates — driver position, trip status, dispatch events — we used Socket.io on top of WebSockets rather than polling. Polling scales linearly with users; a socket-based push model doesn't punish you for having more people watching a live map.

The architecture decision that mattered most, though, was designing for horizontal scale from day one: stateless API nodes behind a load balancer, session and trip state in Redis rather than in memory, and background workers that can scale independently of the web tier. None of it is exotic. It's the boring version of scale, and boring is what survives 3 a.m.