![[System Design] Uber RAMEN: How Ride-Hailing Apps Push Real-Time Notifications to Millions of Devices](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fs7z5yeuon5fvj7ndj468.png)
The Problem: Pushing Instant Notifications to Millions of Devices
Answer-first: Uber's RAMEN system maintains persistent gRPC bidirectional streams to every active driver app. When a match is made, the ride offer travels from the matching engine to the driver's phone in under 100ms β without polling. This is how millions of connections are held open simultaneously without crashing the backend.
When DISCO decides to match you with Driver John Doe, the system must:
- Send the ride offer to exactly John Doe's phone (out of millions of connected phones).
- Deliver it in milliseconds (not seconds).
- Ensure the driver receives it even if their 4G connection is weak.
- Simultaneously push the driver's location back to your app so you can watch the car move on the map.
There are two main approaches: Polling (asking continuously) and Push (proactively sending).
Polling vs. Push
Polling (The Old Way β Inefficient)
The Driver App asks the server every 3 seconds: "Do you have any rides for me?"
GET /api/v1/offers?driver_id=abc123
β Response: { "offers": [] } β Nothing here
GET /api/v1/offers?driver_id=abc123 (3 seconds later)
β Response: { "offers": [] } β Still nothing
GET /api/v1/offers?driver_id=abc123 (3 seconds later)
β Response: { "offers": [...] } β Got a ride! But it's already 0-3 seconds delayed
The Issues:
- 5 million drivers Γ 1 request/3s = 1.67 million requests/second (just asking)
- 99% of requests return empty β Massive waste of server resources
- Latency of 0-3 seconds β Another driver might accept the ride first
- Battery drain: the radio chip must be constantly active
Push (RAMEN β Efficient)
The server maintains an OPEN connection with every driver app.
When a ride offer is ready, the server PROACTIVELY pushes it down instantly.
Driver App ββββ gRPC Stream (live connection) ββββΊ RAMEN Server
Advantages:
- Latency: < 100ms (near-instantaneous)
- No wasted empty requests
- The radio chip is only active when there's actual data to receive
- Significant battery savings
RAMEN β Real-time Asynchronous Messaging Network
RAMEN is the push messaging infrastructure built in-house by Uber. It maintains millions of concurrent persistent connections to push real-time data to rider and driver apps.
Three-Tier Architecture
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β RAMEN Architecture β
β β
β ββββββββββββββββββββ β
β β Fireball Service β "When to push?" β
β β (Decision Engine)β β’ Consumes Kafka events β
β β β β’ Evaluates business rules β
β β β β’ Handles priority, localization β
β ββββββββββ¬ββββββββββ β
β β β
β βΌ β
β ββββββββββββββββββββ β
β β API Gateway β "What to push?" β
β β (Payload Builder)β β’ Aggregates data from services β
β β β β’ Builds message payloads β
β β β β’ Serializes (Protobuf) β
β ββββββββββ¬ββββββββββ β
β β β
β βΌ β
β ββββββββββββββββββββ β
β β RAMEN Server β "How to push?" β
β β (Delivery Layer) β β’ Manages millions of connections β
β β β β’ Routes to the correct device β
β β β β’ Guarantees at-least-once delivery β
β ββββββββββββββββββββ β
β β β
β βΌ β
β Mobile Devices (Millions) β
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
The Evolution of the Transport Protocol
Generation 1: Server-Sent Events (SSE) over HTTP/1.1
Client ββββ HTTP/1.1 Connection βββββΊ RAMEN Server
ββββ SSE (Server β Client only) βββ
Characteristics:
β Simple, browser-friendly
β Unidirectional: only Server β Client
β ACK (acknowledgments) must be sent via separate HTTP POST requests (wasting connections)
β Head-of-line blocking: large messages block smaller heartbeats
β Text-based JSON: heavy payloads
Generation 2: gRPC over QUIC/HTTP3 (Current)
Client βββ gRPC Bidirectional Stream βββΊ RAMEN Server
(HTTP/3 + QUIC)
Characteristics:
β Full-duplex: both sides send data simultaneously on the same connection
β Binary framing (Protobuf): small payloads, low CPU usage
β Multiplexing: multiple streams on 1 connection, no head-of-line blocking
β QUIC: UDP-based, much more resilient on weak mobile networks
β ACKs sent right on the current stream (no separate connection needed)
β Connection migration: switching networks (WiFi β 4G) doesn't break the connection
Scalability: Managing Millions of Connections
Apache Helix + ZooKeeper
RAMEN cannot run on a single server β it requires a cluster of hundreds of servers, each holding tens of thousands of live connections.
RAMEN Cluster Management:
ZooKeeper: Stores topology metadata (which servers are alive?)
Apache Helix: Manages sharding and automatic rebalancing
User UUID "abc123" β hash() β Shard 42 β RAMEN Server #7
User UUID "def456" β hash() β Shard 18 β RAMEN Server #3
If server #7 dies:
1. Helix detects it (heartbeat timeout)
2. Helix moves Shard 42 to server #9
3. Client "abc123" reconnects β Load Balancer β server #9
4. Continues receiving messages seamlessly
Stateful Servers β The Unique Challenge
Unlike standard REST API servers (which are stateless), RAMEN servers are stateful β each server holds specific TCP/gRPC sockets for specific users. Routing must be exact: a message for user "abc123" must reach the exact server holding that user's socket.
Routing Flow:
Fireball: "Push ride offer to driver abc123"
β
βΌ
Routing Layer: hash("abc123") β Server #7
β
βΌ
Server #7: Finds the socket for abc123 in memory β Pushes the message
Ensuring Reliability
At-Least-Once Delivery
Mobile networks are notoriously unreliable β 4G signals can drop for a few seconds and return. RAMEN guarantees that a message is delivered at least once by using:
Persistence Layer:
Cassandra (Durable Storage) Redis (In-Memory Cache)
ββββββββββββββββββββββ ββββββββββββββββββββββ
β Source of truth β β Absorb traffic β
β Stores messages ββββββββββ bursts β
β permanently for β β Thundering herd β
β retries β β protection β
ββββββββββββββββββββββ ββββββββββββββββββββββ
Flow:
1. Message arrives β Written to Cassandra (backup)
2. Cached in Redis (fast access)
3. Pushed via gRPC stream to the device
4. Device sends an ACK
5. If no ACK is received within 10s β Retry from Cassandra
6. Receives ACK β Marks as delivered
Sequence Numbers β Handling Reconnects
When a client loses its connection and reconnects, how does the server know which messages it has already received?
Every message has an incrementing sequence number:
Server β Client:
[seq=1] Ride offer
[seq=2] ETA update
[seq=3] Driver location β Connection lost here
Client reconnects:
"Last received: seq=2"
Server:
β Resends everything from seq=3 onwards (doesn't resend seq=1, seq=2)
[seq=3] Driver location (retry)
[seq=4] Driver location (new)
...
Connection Draining β Preventing Thundering Herds
When deploying new code or scaling down a cluster, RAMEN cannot simply drop millions of connections at once β this would cause a thundering herd (millions of clients reconnecting simultaneously, crashing the entire system).
Graceful Shutdown Flow:
1. RAMEN Server #7 needs to shut down
2. Server #7 stops accepting NEW connections
3. Sends a "Graceful Disconnect" to all currently connected clients
Message: { type: "DISCONNECT", backoff_hint_ms: random(1000, 30000) }
4. Each client receives a different backoff_hint:
- Client A: waits 2.3 seconds, then reconnects
- Client B: waits 15.7 seconds, then reconnects
- Client C: waits 8.1 seconds, then reconnects
5. Reconnections are spread evenly over 30 seconds β no thundering herd
Fallback: Silent Push Notifications
When a driver app is pushed to the background by the operating system (due to Android/iOS power management), the gRPC stream will be closed. In this scenario, RAMEN uses Silent Push Notifications via APNs (Apple) / FCM (Google) to "wake up" the app:
Primary Flow (App in foreground):
RAMEN Server βββΊ gRPC Stream βββΊ Driver App β (< 100ms)
Fallback Flow (App in background):
RAMEN Server βββΊ FCM/APNs βββΊ OS wakes app βββΊ App reconnects gRPC
(Takes 1-5 seconds)
Grab's Approach: WebSocket + Istio
Grab didn't build a massive custom system like RAMEN; they use a simpler approach:
- WebSockets for real-time bidirectional communication.
- Istio Service Mesh manages routing, load balancing, and mTLS.
- FCM/APNs act as fallbacks when the app is backgrounded.
Pros: Simpler to maintain, uses open standards. Cons: WebSockets over HTTP/1.1 suffer from head-of-line blocking and aren't as robust as gRPC/QUIC on weak networks.
Summary of the End-to-End Real-Time Flow
THE COMPLETE REAL-TIME PIPELINE:
β Driver moves
β GPS Sensor β Kalman Filter β Batches 3 points
β gRPC Stream β Load Balancer β Location Service
β‘ Location Service
β Converts GPS β H3 Index
β Produces to Kafka "driver.location.updates"
β’ Kafka β Consumers:
βββ Redis GEO (updates driver's location)
βββ Flink (calculates supply-demand β Surge Pricing)
βββ Analytics Pipeline (Data Lake)
β£ Rider requests a car
β Demand Service β Kafka "ride.requests"
β€ DISCO Matching Engine
β Queries Redis (finds nearby drivers)
β Routing Service (calculates actual ETA)
β Hungarian Algorithm (batched matching)
β Selects the optimal driver
β₯ RAMEN Push
β Fireball (decision) β API Gateway (payload)
β RAMEN Server β gRPC Stream β Driver Phone
β "You have a new ride request!"
β¦ Driver accepts
β Trip Service β Kafka "ride.status.changes"
β RAMEN Push β Rider App: "Your driver is on the way!"
β Location stream starts pushing driver's position to the Rider App
β Car moves smoothly on the map π
Total elapsed time: < 2 seconds
Official Reference Sources
| Source | Content |
|---|---|
| Uber Eng: H3 Hexagonal Index | Hexagonal gridding algorithm |
| Uber Eng: RAMEN | Push messaging architecture |
| Uber Eng: DISCO | Matching Engine |
| Uber Eng: DeepETA | ML model for ETA prediction |
| Grab Eng: Fulfilment Platform | Dispatch platform architecture |
| Grab Eng: DispatchGym | RL framework for dispatch |
| Lyft Eng: Real-time Map Matching | Kalman Filters & Map Matching |
| H3 Documentation | API reference for H3 |
| Google S2 Geometry | API reference for S2 |
Congratulations on completing the series! You now deeply understand every architectural layer behind that smoothly moving car on your map. From the GPS sensor β Kalman Filter β Kafka β H3 β DISCO β RAMEN β Your App. **Every layer represents a fascinating distributed engineering challenge.**
This post was originally published on my blog at Uber RAMEN: How Ride-Hailing Apps Push Real-Time Notifications to Millions of Devices.
Hi, I'm LΓͺ TuαΊ₯n Anh (vesviet) π
I am a Senior Go Backend Architect & Distributed Systems Engineer with 17+ years of experience building high-traffic platforms (25M+ requests/month).
If you enjoyed this deep-dive, let's connect on LinkedIn or explore my consulting services at tanhdev.com/hire.
![[System Design] Part 4 β Amazon CONDOR & Anticipatory Shipping](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fcr7y22086qgqejku95th.png)
![[System Design] GraphHopper Distance Matrix: Self-Host OSRM vs Haversine for Route Optimization](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fyoo5j6x1kubw2zbx6ayz.png)
![[System Design] H3 Geospatial Indexing: How Uber Finds Nearby Drivers with Hexagonal Spatial Index](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fg3rnlk0wj8ndd1rawn37.png)
![[System Design] Surge Pricing Algorithm: How Ride-Hailing Engines Calculate Surge Rate in Real Time](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fz0plffcv5n9mlyjku65i.png)