Concepts
Presence
A time-bounded signal that estimates whether a user or device is reachable, recently active, idle, or unavailable.
Concepts Covered
- User presence
- Device presence
- Heartbeats
- TTL-based liveness
- Stale online status
- Multi-device ambiguity
- Privacy rules
- Presence as a routing hint
Definition
Presence is a time-bounded signal that estimates whether a user or device is currently reachable or recently active.
Examples include:
- online
- last seen recently
- typing
- active now
- device connected
- idle
These labels look simple in the UI, but the backend truth is messy. Presence is not a permanent fact. It is a best-effort signal built from connections, heartbeats, client activity, and expiration rules.
In distributed systems, presence should usually be treated as a hint, not a source of truth.
The Pain That Forces Presence Design
Users expect messaging apps to feel alive. They want to know whether someone is reachable, typing, or recently active.
But mobile networks are unreliable:
phone enters elevator
network disappears
app cannot send clean disconnect
server still thinks socket is open
UI still says online
The server cannot always know the exact truth. It can only observe signals. If heartbeats continue, the device is probably connected. If heartbeats stop, the device is probably gone after some timeout.
Presence exists because realtime systems need a practical way to represent uncertain liveness.
Mental Model
Presence is temporary state with an expiration time.
Instead of storing:
user_7 is online forever
the system stores:
device_id: d_42
user_id: u_7
gateway_id: gw_17
status: connected
expires_at: now + 45 seconds
The record must be refreshed. If it is not refreshed, it expires automatically.
This TTL-based model is important because clients do not always disconnect politely. Expiration lets the system clean up stale presence without needing a perfect disconnect event.
User Presence Versus Device Presence
The distinction matters.
A user can have multiple devices:
user_7
- phone: connected
- laptop: disconnected
- tablet: idle
If one device is connected, is the user online? Maybe. If the phone is connected in the background but the user has not opened the app in hours, should the UI show "online"? That is a product decision, not just a technical one.
Device presence is useful for routing. User presence is useful for product experience. Mixing them can create confusing behavior.
How Presence Is Usually Built
A common design:
1. Device connects to realtime gateway.
2. Gateway authenticates device.
3. Gateway writes presence record with TTL.
4. Device or gateway refreshes through heartbeat.
5. Record expires if heartbeat stops.
6. Other systems read presence as a hint.
The gateway is often the best source for connection presence because it owns the live socket. But product activity, privacy settings, and last-seen behavior may live in another service.
Presence For Routing
Delivery workers may use presence to decide whether to route a message through a realtime gateway.
If presence says the device is connected, the worker attempts realtime delivery. If that attempt fails, the system should fall back to offline delivery.
That fallback is necessary because presence can be stale.
Presence says:
try this path
A delivery acknowledgement says:
the message was received
Those are different guarantees.
Presence For UI
Presence is also a user-facing feature, which makes it sensitive.
Product teams need to define:
- whether online status is exact or intentionally fuzzy
- whether users can hide last-seen status
- whether typing indicators are broadcast to all devices
- whether group presence differs from one-to-one presence
- how quickly the UI should stop showing someone as online
- whether background connections count as active
These choices affect privacy, trust, and perceived correctness.
Operational Reality
Important signals:
- heartbeat success rate
- presence write rate
- expired presence records
- reconnect storms
- gateway-to-presence-store latency
- stale online reports
- privacy setting mismatches
- delivery attempts to stale devices
Failure modes:
- TTL is too long, so users appear online after losing network.
- TTL is too short, so users flicker online and offline.
- Presence writes overload the store during reconnect storms.
- Delivery workers trust presence too much and skip offline fallback.
- Multi-device state collapses into one misleading user status.
Presence is not about perfect truth. It is about useful, temporary confidence.
Related Topics
Knowledge links
Use these links to understand what to know first, where this idea appears, and what to study next.
Prerequisites
Read these first if this topic feels unfamiliar.
Used In Systems
System studies where this idea appears in context.
Related Concepts
Core ideas that connect to this topic.