Design a Read-Receipt Service

Design a read-receipt service for a large consumer chat product. It tracks, for every message, which recipients have received it and which have read it, then pushes those state changes back to the sender in near-real-time so the familiar single-tick, double-tick, and read markers stay current.

Operating context. The messaging core already delivers message payloads and owns the socket to each device; your service consumes receipt events (delivered, read) emitted by recipient devices and is the source of truth for receipt state. Traffic is heavy and bursty: 50,000 receipt events/sec at steady state, spiking to 200,000/sec in the evening peak. Both one-to-one and group conversations exist, and large groups can hold up to 100,000 members, so a single read in a group must not trigger a write per member. Senders expect their tick to update within a couple of seconds while they have the chat open.

Out of scope. Message content storage and delivery, presence and last-seen, push-notification fan-out, and end-to-end-encryption key management are owned by other teams. Assume you receive authenticated, deduplicated device identities.

What to produce. A high-level architecture covering: how receipt events are ingested and made durable, the per-message state model and its partitioning, how group conversations are aggregated without O(N) write amplification, how a state change is propagated back to the sender's online devices, and how you keep the whole thing idempotent under device retries. Sketch the components and the event flow; checkpoints will probe the group fan-in and the idempotency choices.