How Does Uber Know Your Driver Moved Without You Refreshing the App?

Your Uber driver moves 200 meters. You don't refresh the app. Yet the car moves on your screen. A few seconds later: "Driver arriving in 4 min." Then 3. Then 2.

How does your phone know? It isn't repeatedly asking "did the driver move?" That's not how a large-scale real-time system works.

A simplified architecture looks like this:

1. 🚗 The driver's phone sends location updates.
2. 📍 A location service receives the update.
3. ⚡ An event is published.
4. 🌐 Streaming infrastructure processes the location change.
5. 📡 A real-time gateway pushes the relevant update to the rider.
6. 📱 The frontend updates its state — no page refresh, no full-screen API request, just a stream of state changes.

But the interesting part isn't sending the event. It's everything that happens when reality isn't perfect.

• What if the driver's phone loses connectivity?
• What if two location events arrive out of order?
• What if the rider temporarily loses their network?
• What if an event is duplicated?
• What if the frontend misses several updates?

A production system can't assume every event will arrive exactly once, in order, immediately. Instead, it needs event processing, deduplication, ordering and timestamps, connection recovery, state reconciliation, fresh snapshots, and scalable fan-out.

There's another important optimization too. A rider doesn't need the location of every driver in the city — only the ones relevant to their trip. Don't distribute every event to everyone. Filter and route events to the users who actually need them.

The deeper lesson: Real-time systems aren't built by making everything real-time. They're built by deciding what changed, who needs to know, how quickly they need to know, and what happens when the update is missed.

That's the difference between a demo that moves a marker on a map, and a production system that can do it reliably at scale.

What other real-time system should we break down next?