Chat delivery: define what each tick means
This is a hypothetical chat-service design. It does not claim to reproduce WhatsApp or Telegram's transports, databases, retention, or current cryptographic implementation. The exercise separates transport connectivity from message durability and privacy.
Workload and delivery contract
Assume 500,000 daily users each sending 50 messages. That is 25 million messages per day, or about 289 per second on average. At an assumed 1 KiB per encrypted envelope, ingress is 25.6 GB/day before attachments, indexes, replicas, and recipient fan-out. A 100-member group can require many device deliveries for one submitted message.
Define three application states:
| State | Evidence |
|---|---|
| Accepted | The service has durably recorded the encrypted envelope and delivery work |
| Delivered | A designated recipient device has acknowledged its defined receipt step |
| Read | The recipient client explicitly reports opening or reading it, subject to preferences |
The product must decide whether “delivered” means any recipient device or every registered device. A network write succeeding is not the same as the recipient saving the message.
Message Delivery Lifecycle
Hey, are you free for coffee? ☕
The demonstration illustrates these states. Production transitions need durable records and repeatable processing behind the visual feedback.
Use a transport, then add a protocol
WebSocket is one option for a connected browser client. It is a message-framed protocol layered over a connection, not merely an unstructured byte stream. It still does not define chat IDs, application acknowledgments, reconnect recovery, or retention. WebSocket specification, RFC 6455.
An envelope might contain a conversation ID, sender device ID, client-generated message ID, encrypted payload, and protocol version. Authenticate the connection and authorize conversation membership for every send. Bound message size, outstanding sends, and outbound queues so one slow connection cannot exhaust the gateway.
Native mobile clients may use other persistent transports and push notifications as wake-up hints. The server's durable mailbox must remain the source for recovery; a push notification is not proof that the underlying chat message reached the user.
Follow a lost acknowledgment
Alice sends message M. The server inserts M and its delivery work transactionally, then acknowledges acceptance. The acknowledgment is lost, so Alice sends M again after reconnecting.
A unique (sender_device_id, client_message_id) constraint identifies the retry. The server returns the existing result instead of making a second message. If a gateway acknowledged before persistence and then crashed, Alice could believe an unrecorded message was safely sent. Durability must precede the application acceptance signal.
The delivery worker may send M more than once if a recipient acknowledgment is lost. The recipient deduplicates by message identity and acknowledges again. This is repeatable delivery with idempotent handling, rather than a claim that the network transmits each message exactly once.
Ordering and device sync need their own rules
For a simple design, assign a monotonically increasing sequence within each conversation at the authoritative conversation shard. That supplies an ordering for display and cursor-based synchronization. It does not prove that two people typing at the same time experienced the same real-world order.
Track device delivery cursors. A device reconnects asking for messages after its last stored cursor; it should advance that cursor only after saving the batch. If the server has expired the history, report the gap and use the chosen recovery mechanism. Silently returning an empty batch would conceal missing messages.
Group membership is versioned. Define whether a new member receives old history and ensure removed members do not receive new delivery work. Device addition, removal, and replacement are membership changes too.
Encryption changes where work can happen
For end-to-end encrypted content, encryption and decryption occur at authorized endpoints; a delivery server routes ciphertext. Use a maintained, reviewed implementation of an established protocol rather than inventing encryption from a sketch.
The Signal Double Ratchet specification describes evolving message keys and recovery properties under stated assumptions. Those properties depend on key agreement, identity authentication, state handling, and compromise conditions; merely changing a key every message is not a complete security design. Signal Double Ratchet specification.
A server cannot generally perform plaintext search or generate arbitrary message previews over content it cannot decrypt. Group encryption also needs a membership-aware key protocol; sending one plaintext message to a server and asking it to encrypt for everyone would cross the endpoint-only privacy boundary. Routing metadata and timing can remain visible even when message content is encrypted.
Test a lost sender acknowledgment, duplicate recipient delivery, an offline device returning after expiry, and membership removal during queued delivery. Check duplicate display, gaps, queue age, and the precise meaning of every receipt. This makes reliability and privacy observable properties of the workflow.
Keep reading
Ride Matching: Spatial Search and Safe Assignment
Work through stale locations, geographic candidate selection, concurrent driver offers and fenced trip assignments.
Social Feed Design: Fan-out, Ranking and Privacy
Work through a hybrid social-feed design, estimate write amplification, and handle deletion, privacy changes and stable pagination.
API Gateway Pattern
The single entry point for microservices. Implementing rate limiting, authentication, and protocol translation/aggregation.
File Synchronization: Versions, Conflicts and Recovery
A worked file-sync design: immutable blocks, version checks, offline conflicts, and safe cleanup. Includes a clearly scoped Dropbox engineering reference.
Geohashing (Location Encoding)
A geocoding system that encodes latitude/longitude coordinates into short alphanumeric strings for efficient proximity searches and spatial indexing.
Notification Delivery: Queues, Retries and Deadlines
Design a notification service around provider acceptance, recipient delivery, retry ambiguity, queue age and changing preferences.