Telegram Delivery & Read Receipt Architecture: Single vs Double Checkmark Semantics & MTProto Read History
Few UI elements generate as much curiosity and misunderstanding as chat checkmarks. Unlike SMS or legacy client-to-client networks, Telegram's checkmark semantics reflect its distributed cloud architecture. On Telegram, one checkmark (✓) signifies that your message has been delivered to Telegram's cloud cluster and synced across all recipient sessions—even if their physical smartphone is currently powered off. Two checkmarks (✓✓) confirm that the recipient has opened the conversation and viewed the bubble. In groups, a message is marked as read as soon as at least one member views it.
- arrow_forward 1. Single Checkmark: Ingested & Cloud Distributed
- arrow_forward 2. Double Checkmark: Viewport Hit Testing & Read State
- arrow_forward 3. Group Chat Read Semantics & Scalability
- arrow_forward 4. MTProto messages.readHistory Protocol
- arrow_forward 5. Interactive Delivery & Read Receipt Studio
- arrow_forward 6. Executive Infographic & Production Blueprint
1. Single Checkmark: Ingested & Cloud Distributed
In legacy SMS or peer-to-peer protocols, a delivery receipt implies a hand-off to the recipient's specific physical hardware. Telegram operates on a distributed cloud topology. When a sender presses send, the client dispatches messages.sendMessage:
Message Ingested by Datacenter -> Replicated across Cloud Storage Clusters -> Synced to Recipient Outbox Stream -> Push Notifications Dispatched via APNs / FCM.
The message is delivered whether the friend's phone is switched on, in flight mode, or out of cell coverage. As soon as any of their devices connects, the message downloads instantly.
2. Double Checkmark: Viewport Hit Testing & Read State
A message changes from one checkmark to two checkmarks (✓✓) exclusively when the recipient opens the conversation:
Merely receiving a lock-screen push notification does not trigger a read receipt. The recipient must launch Telegram and render the message in the visible viewport.
When a user scrolls to message #500, all preceding messages (#1 to #500) automatically transition to read state in a single atomic pointer increment.
The sender client receives an updateReadHistoryOutbox socket event, updating the checkmark icon smoothly in real time without refreshing.
3. Group Chat Read Semantics & Scalability
In large groups (which can hold up to 200,000 members on Telegram), tracking every individual read event per checkmark would cause catastrophic database lock contention:
In group chats, the message icon transitions to double checks (✓✓) as soon as at least one member views the message. In smaller groups, tapping or right-clicking the bubble opens a granular viewer list displaying exactly which members have read the message and at what time.
4. MTProto messages.readHistory Protocol
Under the MTProto transport protocol, acknowledging message reads utilizes a streamlined RPC method:
messages.readHistory#0e306d3a peer:InputPeer max_id:int = messages.AffectedMessages;
Rather than transmitting hundreds of message IDs, the client simply provides the max_id. The server updates the outbox pointer in constant time O(1) and broadcasts socket updates to sender sessions.
5. Interactive Delivery & Read Receipt Studio
Experience Telegram's checkmark lifecycle. Switch between 1-on-1 and Group Chat modes. Dispatch messages and simulate recipient open events to watch checkmarks transition in real time!
Telegram Delivery & Read Architecture at a Glance
A comprehensive visual flowchart summarizing cloud delivery guarantees, viewport read triggers, and group chat any-member thresholds.
