Designing Presence for a Large-Scale Real-Time Platform
Presence is one of those systems that users never notice when it works correctly.
Drivers appear online.
Passengers immediately see available rides.
Messages arrive instantly.
Ride requests are delivered to active drivers.
Everything simply feels live.
Behind the scenes, however, every one of those features depends on answering a deceptively simple question:
Who is online right now?
Building a reliable presence system became a foundational part of the platform because nearly every real-time feature relied on it.
Presence Is More Than Online or Offline
At first, it seems sufficient to store a simple boolean indicating whether a user is connected.
In practice, that quickly falls apart.
Drivers may connect from multiple devices.
Mobile applications frequently disconnect and reconnect while switching networks.
Temporary connection loss shouldn't immediately make a driver disappear from nearby ride searches.
Likewise, a passenger who briefly loses connectivity shouldn't be treated as if they've abandoned an active ride.
Presence therefore became a continuously changing state rather than a simple flag.
Why Redis Became the Source of Truth
Presence changes constantly.
Every connection, disconnection, heartbeat, and reconnect generates updates.
Persisting those operations directly in the primary database would create unnecessary write traffic while slowing features that depend on immediate availability.
Instead, Redis became the authoritative store for live presence.
Each active user maintains lightweight session data containing information such as:
- connection status
- socket identifiers
- active role
- ride participation
- last heartbeat
- current availability
Because everything resides in memory, the platform can determine whether a participant is online within milliseconds.
Presence changes far more frequently than business data.
Redis is optimized for rapidly changing in-memory state, allowing the database to remain focused on long-lived business records instead of temporary connection information.
Powering Multiple Features
The presence service was intentionally designed as shared infrastructure rather than something owned by the messaging system.
Ride dispatch uses it to identify available nearby drivers.
Private ride offers are sent only to drivers currently accepting requests.
Messaging checks presence before determining whether recipients should receive immediate socket events or deferred notifications.
Ride progress uses it to determine which participants should receive live updates.
Even typing indicators and online status rely on the same service.
Instead of every module implementing its own connection tracking, they all consume a common presence layer.
Handling Disconnects Gracefully
Disconnecting doesn't necessarily mean a user has gone offline.
Mobile operating systems routinely suspend network connections for short periods.
Removing users immediately would cause drivers to disappear from dispatch pools and passengers to appear offline during active trips.
To avoid unnecessary churn, the platform introduces a short grace period before marking users as offline.
If the client reconnects within that window, the existing session simply continues.
Only when the timeout expires is the user removed from the active presence registry.
This approach greatly reduces connection instability without compromising the accuracy of availability information.
Presence Drives Business Decisions
One of the most important lessons was recognizing that presence isn't merely a user interface feature.
It directly influences business workflows.
Dispatch decisions depend on driver availability.
Ride offers depend on active connections.
Notification delivery depends on whether users are currently online.
Chat behavior changes depending on recipient presence.
As the platform evolved, presence became one of the most frequently consulted services in the backend.
Rather than exposing socket information directly, every feature asks the presence service one simple question:
"Can this user receive real-time communication right now?"
Presence should never belong to messaging, ride dispatch, or notifications individually.
By centralizing connection awareness into a dedicated service, every feature benefits from consistent behavior while avoiding duplicate connection-tracking logic throughout the codebase.
Lessons Learned
Real-time applications are built on much more than WebSockets.
They require an accurate understanding of who is available, who can receive events, and how temporary connection failures should be handled.
By treating presence as a dedicated infrastructure service backed by Redis, the platform created a reliable foundation that powered ride dispatch, messaging, notifications, and every other real-time feature without each subsystem needing to reinvent connection management.