Presence & Online Status

The Problem

Messaging apps, collaboration tools, and social platforms need to show whether users are currently online, idle, or offline. This seems simple but becomes a hard distributed systems problem at scale — millions of users constantly transitioning between states, each state change needing to fan out to potentially thousands of subscribers (friends, team members, channel participants). The system must handle network partitions, clock skew, and the inherent unreliability of client heartbeats while keeping the status reasonably accurate and the infrastructure cost manageable.

Architectural Approaches

Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Multi-Device Presence Aggregation

When a user has multiple devices (phone, laptop, tablet), presence must be aggregated:

Rules:

• User is online if ANY device is active
• User is idle if ALL devices are idle
• User is offline if ALL devices are disconnected
• User’s status shows the most active device state

Implementation: Store a set of connected devices per user in Redis (SADD/SREM). On any device event, compute the aggregate status:

1. Device connects → SADD user:devices device_id, SET user:status online
2. Device heartbeat → UPDATE user:device:{id}:last_seen
3. Device disconnects → SREM user:devices device_id
4. If device set empty → SET user:status offline
5. If all devices idle → SET user:status idle

Use Redis transactions (MULTI/EXEC) to make aggregate computation atomic.

Fan-Out Optimization

The biggest scalability challenge is fan-out: when a user’s status changes, who needs to know?

Naive approach: Notify all friends/contacts. For a user with 500 friends, each status change triggers 500 push notifications. If 100K users come online in a minute (morning rush), that’s 50M notifications/minute.

Optimizations:

• Lazy fan-out: Only notify users who currently have the status-changed user visible (open chat, visible friend list). Track “active subscriptions” rather than the full social graph.
• Batching: Buffer status changes for 2-5 seconds and send batched updates. Reduces message count dramatically during mass online/offline events.
• Tiered updates: Immediate notification for active conversations, batched for friend list, dropped for background contexts.
• Bloom filter: Use a Bloom filter to quickly check if any online user is subscribed to updates for a given user, avoiding unnecessary fan-out queries.

WhatsApp famously limits presence to one-on-one chat views — you only see someone’s status when you’re actively in a conversation with them. This reduces fan-out from O(friends) to O(1).

Consistency vs Availability

Presence is an inherently eventually consistent system. Trade strict accuracy for availability and performance.

Acceptable inaccuracy: It’s okay if a user appears online for 30-60 seconds after closing the app. It’s NOT okay if a user appears offline while actively chatting.

Design principles:

• Bias toward online: If uncertain, show online. False positives (showing online when offline) are less harmful than false negatives.
• Exponential backoff on offline: Don’t immediately show offline on a missed heartbeat — wait for 2-3 missed intervals. Network is unreliable.
• Local caching: Cache presence state on the client for 10-30 seconds. Don’t re-query on every screen load.
• Graceful degradation: If the presence service is down, show “status unavailable” rather than “offline” for everyone.

Consistency across regions: For multi-region deployments, replicate presence data asynchronously. Accept that users in different regions may see slightly different presence states for a brief window.

Real-World Examples

Architectural Tradeoffs

# Learn the System Design of: Presence & Online Status

You are an expert software architect and teacher. I want to understand presence & online status as a practical system design capability. (Distributed heartbeat tracking to show who is online in real time).

Use the following architectural guide as a learning reference. Avoid one-size-fits-all recommendations. Keep assumptions, costs, and tradeoffs explicit.

---

import { Mermaid, ComponentList, ComponentCard, ApproachList, Approach, Example, Tradeoff } from '@/components/mdx';

## The Problem

Messaging apps, collaboration tools, and social platforms need to show whether users are currently online, idle, or offline. This seems simple but becomes a hard distributed systems problem at scale — millions of users constantly transitioning between states, each state change needing to fan out to potentially thousands of subscribers (friends, team members, channel participants). The system must handle network partitions, clock skew, and the inherent unreliability of client heartbeats while keeping the status reasonably accurate and the infrastructure cost manageable.

## Architectural Approaches

<ApproachList>
<Approach
  name="Heartbeat with TTL-Based Expiry"
  pros={[
    'Extremely simple to implement — just SET with TTL',
    'Stateless servers — any server can process any heartbeat',
    'Naturally handles crashes — TTL expires automatically',
    'Low per-user memory footprint (~100 bytes per user)',
  ]}
  cons={[
    'Offline detection is delayed by the TTL window (30-60s)',
    'Heartbeats generate constant write traffic even for idle users',
    'No distinction between "offline" and "app backgrounded"',
    'Fan-out of status changes must be handled separately',
  ]}
>
Clients send periodic heartbeat signals (every 15-30 seconds). The server stores each user's last heartbeat timestamp in a fast key-value store with a TTL slightly longer than the heartbeat interval. If the key expires, the user is considered ...

[Full prompt copied to clipboard]