The single gray checkmark, the double gray checkmark, and the double blue checkmark are, per-message, some of the most information-dense two-pixel icons in modern software. In the space of a tiny status indicator, a messaging platform is communicating a precise claim about the physical state of a byte string somewhere on a stranger’s phone: it left your device, it arrived at the server, it reached the recipient’s device, and — if read receipts are enabled — a human being actually looked at it. Getting that claim right, consistently, across unreliable mobile networks, offline devices, multiple simultaneous devices per user, and group chats with hundreds of members, turns out to be a surprisingly deep distributed-systems problem.

Delivery confirmation predates modern chat apps by decades. Email’s read receipt mechanism (via the Disposition-Notification-To header, standardized in RFC 8098) was one of the earliest attempts at this, but it was famously unreliable — mail clients could ignore the request entirely, and the feature was widely considered spammy and untrustworthy. SMS took a different approach: telecom carriers implemented delivery reports at the protocol level (SMS-STATUS-REPORT), giving a sender a “delivered” confirmation from the carrier network itself, though never true read confirmation, since carriers have no visibility into whether a human opened a text.

Modern OTT (over-the-top) messaging platforms — BlackBerry Messenger (BBM) is widely credited as the app that popularized the “D” and “R” delivery/read indicators for a mass consumer audience in the late 2000s — reinvented this problem for an always-connected, app-controlled context, where the platform itself (not the carrier) owns both endpoints and can build a much richer, more accurate status pipeline. WhatsApp’s checkmarks, iMessage’s “Delivered”/“Read” text, and Telegram’s checkmark pair are all descendants of this same idea, each making slightly different trade-offs between accuracy, user privacy, and — the focus of this tutorial — how much network chatter it costs to keep that status accurate in near real time across a platform with billions of messages sent per day.

2.1 Functional Requirements

• A sender can see, per message, whether it is: sent (left the sender’s device and was accepted by the server), delivered (reached at least one of the recipient’s active devices), and read (the recipient viewed it, if read receipts are enabled).
• In a group chat, the sender can see an aggregate view — e.g., “delivered to 8 of 10,” “read by 6 of 10” — and, optionally, a per-member breakdown.
• Status must correctly account for a recipient having multiple active devices (phone, tablet, web/desktop client) — a message is “delivered” once any device receives it, but “read” semantics need a clear, consistent policy across devices (see 4.4).
• Users can disable read receipts (and, on many platforms, doing so also disables seeing others’ read receipts — a reciprocal privacy design, discussed in the security section).
• Status updates must eventually reach the sender even if the sender was offline at the moment the recipient read the message — i.e., the receipt itself needs reliable, not just best-effort, delivery back to the sender.

2.2 Non-Functional Requirements

3.1 Core Components

4.1 The Status State Machine

Each message, for each recipient, moves through a small, strictly-ordered state machine. Modeling this explicitly as a state machine — rather than as loosely-typed boolean flags — is what prevents the classic bug of a message appearing to “un-deliver” when events arrive out of order.

The critical invariant enforced by the aggregation logic is monotonicity: status can only move forward (Sent → Delivered → Read), never backward, regardless of the order in which raw events physically arrive at the server. If a “read” event somehow arrives before a “delivered” event was fully processed (plausible under network reordering, since these are typically sent as independent messages over possibly different connections or retried separately), the aggregation service should still resolve the final state to “read” and treat the missing “delivered” event as implied, rather than getting stuck or, worse, showing “delivered” after the sender already correctly saw “read.”

4.2 Batching and Debouncing: The Core Chatter-Reduction Technique

This is the crux of the entire design problem. Two closely related but distinct techniques do most of the work:

• Batching: rather than sending one network message per status event, the recipient’s client (and the server’s aggregation layer) accumulate multiple status transitions over a short window and send them together as a single batch. If a user opens a chat and reads 15 unread messages in the span of two seconds, that should produce one batched “read up to message #N” acknowledgement, not 15 individual ones.
• Debouncing: waiting for a short quiet period (typically a few hundred milliseconds to a couple of seconds) before emitting a status update, so that rapid-fire changes collapse into a single final update rather than emitting one update per intermediate state.

The single highest-leverage design decision here is using a “read up to” cursor rather than per-message read acknowledgements. Instead of the recipient’s client saying “message 1042 was read,” “message 1043 was read,” “message 1044 was read” as three separate events, it says “everything up to and including message 1044 has been read” as one event. This collapses what would be O(n) acknowledgements for n messages read in a session down to O(1) — a single cursor update — and is the single most impactful chatter-reduction technique in the entire design, because in practice users very often read messages in contiguous batches (opening a chat and scrolling through everything since their last visit) rather than one at a time.

4.3 Piggybacking Acknowledgements

A second major technique is piggybacking: rather than emitting a dedicated network round-trip purely to carry a delivered/read acknowledgement, attach that acknowledgement to other traffic that’s already flowing over the same persistent connection — for example, riding along on the client’s periodic connection heartbeat/keepalive, or bundling it with the client’s own next outbound message in that conversation. This further reduces the marginal network cost of acknowledgements toward zero in the common case where the connection is already being kept warm for other reasons.

4.4 Multi-Device Semantics

Modern messaging users routinely have multiple simultaneously-linked devices (phone, tablet, desktop/web client). This complicates both “delivered” and “read” semantics:

• Delivered is typically defined as “delivered to at least one active device” — the first device to successfully receive the message triggers the delivered status, and the aggregation service does not wait for or require every device to acknowledge.
• Read is more subtle. Common policy is “read on any device counts as read everywhere” — if a user reads a message on their phone, the desktop client’s unread badge should also clear, and the sender should see “read.” This requires the platform to synchronize read state across a user’s own device fleet (a separate, smaller-scale sync problem nested inside the larger one), typically via a per-user “read cursor” broadcast to all of that user’s own linked devices whenever it advances.

5.1 Write Path for Status Events

1. Recipient device receives a message and, on successful local persistence, schedules a delivered-acknowledgement (often near-immediate, since delivered status is comparatively cheap and high-value for sender UX).
2. Delivered acknowledgements are lightweight enough that they are typically sent close to real time (sub-second to low-single-digit-second delay) rather than heavily batched, since there’s usually only one such event per message and batching gains are smaller here than on the read side.
3. When the user actually views messages, the client updates its local “read up to” cursor and starts a debounce timer (commonly a few hundred milliseconds) rather than sending immediately, so that rapid scrolling through many messages collapses into a single cursor update.
4. The cursor update is sent to the Status Aggregation Service, which persists the new read boundary, updates the message-level status for all messages at or before that boundary, and — for the sender’s benefit — schedules a batched status notification rather than notifying the sender per-message.
5. For group chats, the aggregation service additionally maintains a per-recipient delivered/read cursor and computes the aggregate “delivered to X of Y / read by X of Y” summary that the sender’s client actually renders, rather than the sender’s client having to compute this itself from N individual streams.

5.2 Lifecycle of a Status Update Under Failure

If the recipient’s connection drops before an acknowledgement is sent, the acknowledgement is simply lost from the network’s perspective — but because the true read/delivered state lives durably on the recipient’s own device (it actually did receive/read the message), the client re-sends its outstanding acknowledgements as soon as it reconnects, using the same “up to cursor N” idempotent model, so a dropped connection causes at most a delay, never an incorrect final state. This idempotency is what makes at-least-once delivery of acknowledgement events safe: duplicate delivery of the same cursor update is a harmless no-op on the server, since applying “read up to message 1044” twice has the same effect as applying it once.

7.1 Estimating Chatter Volume

Consider a platform sending 20 billion messages per day. A naive, unbatched design generates roughly one delivered event and one read event per message per recipient — for 1:1 chats alone, that’s up to 40 billion extra small network events per day, on top of the 20 billion message sends themselves, effectively tripling total message-layer traffic. Applying the “read up to” cursor with debouncing, informed by realistic usage patterns (users commonly read 5–20 messages per chat-opening session as one burst), can plausibly collapse the read-side volume by an order of magnitude or more, since a session that would have generated 15 individual read events instead generates one cursor update. This is the kind of estimate worth walking through explicitly in an interview to justify why batching isn’t just a nice-to-have but a load-bearing scalability requirement.

7.2 Group Chat Fan-Out Cost

Status tracking cost in a group chat scales with the number of members, not just the number of messages, since each member independently generates delivered and read events for each message. A 500-member channel where everyone eventually reads every message could generate 500 status events per message if handled naively — completely impractical at scale. Production systems address this by (a) aggressively batching and coalescing per-member status into periodic summary updates rather than individual pushes, (b) for very large groups, sometimes dropping granular read-receipt tracking altogether in favor of a much coarser signal (e.g., “seen by 240+ people” rather than an exact, continuously-updated count), and (c) rate-limiting how frequently the aggregate summary is recomputed and pushed to the sender — e.g., at most once every few seconds, rather than on every single incoming status event.

7.3 Server-Side Batching of Outbound Status Pushes to the Sender

Beyond reducing chatter from the recipient side, the server itself should batch outbound status notifications to the sender: rather than pushing a fresh status update to the sender’s device the instant any underlying event arrives, the Status Aggregation Service can accumulate status changes for a short window (a common pattern is a small fixed window, e.g., 500ms–2s) and flush a single combined update, which matters enormously for active senders in busy group chats where dozens of read events might otherwise trigger dozens of separate pushes to the sender’s device in quick succession.

7.4 Back-of-the-Envelope: Sizing the Status Store

Walking through rough numbers again clarifies why the cursor model matters so much operationally. Suppose a platform has 500 million daily active users, and each user is, on average, an active participant in 15 conversations per day, opening each conversation roughly 4 times daily (checking for new messages throughout the day). With a naive per-message acknowledgement model, if the average conversation-opening session involves reading 6 unread messages, that’s 500M × 15 × 4 × 6 ≈ 180 billion individual read events per day. With the cursor model, that same activity collapses to at most 500M × 15 × 4 ≈ 30 billion cursor updates per day — and in practice considerably fewer, since debouncing further coalesces rapid successive opens of the same conversation within a short window. That’s roughly a 6x reduction from this technique alone, before even accounting for the piggybacking and server-side batching layered on top — a concrete illustration of why cursor-based tracking isn’t a minor optimization but the single biggest lever in the whole design.

7.5 Choosing Debounce and Batch Windows

The actual numeric values for debounce and batch windows are a tuning problem, not a fixed constant, and should be informed by real usage data rather than picked arbitrarily. A useful mental model: the debounce window should be long enough to capture the vast majority of a natural “reading burst” (empirically, most users finish scanning a handful of new messages within one to two seconds of opening a chat) but short enough that the sender doesn’t perceive a lag when watching for a reply to a message they just sent, which is the moment sender attentiveness — and therefore sensitivity to receipt latency — is highest. Many production systems land in the 300ms–1.5s range for read-cursor debouncing and a similarly short window (200–500ms) for server-side batching of outbound status pushes to the sender, with these values typically exposed as tunable configuration rather than hardcoded, so they can be adjusted based on observed metrics (see Section 10) without a code deployment.

9.1 Read Receipts as a Privacy-Sensitive Feature

Whether someone has seen a message — and when — is meaningfully sensitive personal information; it can reveal availability, attentiveness, or even relationship dynamics (the classic “they read it and didn’t reply” anxiety). Because of this, read receipts are almost universally implemented as an opt-in or reciprocally-toggleable feature rather than an always-on default: a common and well-regarded pattern (used by WhatsApp, among others) is that if a user disables sending read receipts, they also lose the ability to see others’ read receipts — a reciprocal design that discourages one-sided surveillance (watching others’ read status while hiding your own) and keeps the feature socially fair.

9.2 Access Control on Status Data

Delivery and read status for a message should only ever be visible to the sender of that message (and, for group aggregate counts, potentially visible more broadly depending on product design) — never to unrelated third parties. This needs the same conversation-membership-based access control discussed for message content itself: the Status Aggregation Service should verify that any client requesting status information is actually the sender (or an authorized participant) of that specific message before returning data.

9.3 Metadata Minimization

Precise read timestamps are more revealing than coarse ones. Some platforms deliberately round or bucket read timestamps (e.g., to the nearest minute) rather than exposing millisecond precision, reducing the granularity of inferences a sender could draw (such as detecting exactly how long a recipient took to open a specific message during a specific narrow window). This is a privacy-by-design trade-off worth calling out — perfect accuracy is not always the goal even where it would be technically easy to achieve.

9.4 Encryption Considerations

For end-to-end encrypted platforms, delivery and read receipts themselves are typically also encrypted or otherwise protected in transit, since even metadata like “message X was read at time Y” can be sensitive; the acknowledgement payloads should not leak message content and should be authenticated (so a malicious actor cannot forge a false “read” receipt on someone else’s behalf, which would be a meaningful integrity violation given how socially significant read status can be).

9.5 Regulatory Considerations

In jurisdictions with strict data protection regimes (e.g., GDPR in the EU), read status is generally considered personal data about the recipient (it reveals behavior — when and whether they engaged with content), which means it’s subject to the same lawful-basis, consent, and retention-limitation requirements as other personal data categories. Practically, this reinforces the case for treating the read-receipts opt-out as a genuine, server-enforced consent mechanism rather than a cosmetic setting, and for not retaining fine-grained historical read-timestamp data longer than the platform has an actual product justification for — a “read at 3:42:17pm on March 3rd two years ago” record that no feature actually uses is retained regulatory risk with no offsetting product value.

Because status data is high-volume and comparatively low-stakes per individual event, it’s a good candidate for sampled logging and metrics rather than exhaustive per-event logging, which itself would reintroduce a meaningful amount of the “chatter” the design is trying to minimize — even the observability layer needs to respect the same efficiency principle as the feature it’s observing.

The Status Aggregation Service is a natural candidate for a horizontally-scaled, stateless (or lightly-stateful, with externalized state in a fast store like Redis or a purpose-built key-value store) service deployed behind the same connection layer that handles live WebSocket/MQTT connections, since status updates are so tightly coupled to connection lifecycle events (connect, disconnect, reconnect). It benefits from being deployed close to the connection-handling infrastructure (same region/AZ where possible) to minimize the latency of the fast-path delivered acknowledgement, while the batching/debouncing logic itself is comparatively latency-insensitive and can tolerate being one hop further away if needed for operational simplicity.

Push notification delivery (APNs/FCM) is inherently an external dependency outside the platform’s direct control, and deployment needs to account for provider-side rate limits and quotas — batching push-triggered wake-ups where possible, and building in backoff/retry logic for provider-side throttling, is a deployment-level concern as much as an application-level one.

12.0 Choosing Between Push and Pull for Status Retrieval

There are two general models for getting status updates to the sender: server-initiated push (the server proactively notifies the sender’s client the moment a batched status update is ready) and client-initiated pull (the sender’s client periodically polls for status on its recently-sent messages). Push is strongly preferred for the primary experience, since it enables the low-latency “delivered” and reasonably-fresh “read” indicators users expect without wasteful polling overhead, but a pull-based reconciliation path is still valuable as a fallback — for instance, when a client reconnects after being offline for an extended period, a single explicit pull request for “status of all my messages sent since I went offline” is more efficient than replaying a long backlog of individual push events that occurred while disconnected.

12.1 Status Store Design

The status store’s natural access pattern — frequent small updates keyed by (message_id, recipient_id) or, more efficiently, by (conversation_id, recipient_id) for the cursor-based model — favors a wide-column or key-value store optimized for high write throughput and simple point lookups (Cassandra/ScyllaDB, DynamoDB, or a Redis-backed store for the hottest, most recent data) over a relational database, which would struggle with the sheer update volume even after batching optimizations are applied.

12.2 Caching

Because most status queries are “what’s the current status of this sender’s recently-sent messages,” a cache of recent per-conversation status state (keyed by conversation, holding the current read cursor per member) serves the overwhelming majority of status-related reads without touching the durable store, and this cache can itself be the primary read path for the fast-moving cursor model, with the durable store acting more as a periodically-flushed backing store and source of truth for reconnection resync than as the primary hot-path read target.

12.3 Load Balancing

Status update traffic should be load-balanced across Status Aggregation Service instances using a consistent-hashing scheme keyed by conversation_id (so all status traffic for a given conversation lands on the same instance, enabling efficient in-memory batching/debouncing state without cross-instance coordination), similar in spirit to the user-based sharding strategy used for search, but keyed differently to match this subsystem’s own dominant access pattern.

Keeping the Delivery Service and Status Aggregation Service as distinct components (rather than folding acknowledgement handling directly into the Messaging Service) mirrors the separation-of-concerns principle used throughout this design: message delivery and status tracking have different reliability requirements, different scaling drivers, and different failure-isolation needs, and coupling them tightly would make it harder to evolve or scale either independently.

13.1 API Design Details

The POST /status/ack endpoint (or its equivalent persistent-connection message frame, for clients that maintain a live WebSocket rather than issuing discrete HTTP calls) should accept a compact payload built around the cursor model: a conversation identifier, the highest message sequence number confirmed as delivered or read, a status type (delivered vs. read), and a client-side timestamp. Keeping this payload minimal matters directly for the chatter-reduction goal — every additional field is additional bytes multiplied across billions of daily events. The response, correspondingly, should be minimal or entirely absent (fire-and-forget over a reliable transport, relying on transport-level acknowledgement rather than an application-level response payload) wherever the underlying connection already guarantees delivery, avoiding a redundant round trip purely to confirm receipt of an acknowledgement.

14.1 Patterns Used

14.2 Anti-patterns to Avoid

The two-checkmark indicator looks like a design detail. It’s a distributed system in disguise — and every millisecond of user-perceived accuracy is bought or saved in the batching windows, the cursor semantics, and the boring, load-bearing decoupling between what the sender sees and how the message actually got there.