SYSTEM DESIGN · QUESTION 29
How would you design a reliable messaging service?
On this page
I would clarify whether the product needs direct or group messaging, delivery guarantees, ordering, online status, and retention. A typical design authenticates clients, accepts messages through an API, stores them durably, and uses queues or event delivery to notify recipients. I would make message IDs idempotent, track delivery state, and handle offline recipients. Ordering, fan-out, privacy, and latency are key trade-offs.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A messaging service must do more than move text between two phones. It needs to accept a message, keep it safe, deliver it when a recipient is available, and avoid showing duplicates when networks retry. It also needs to control who can read a conversation. The architecture depends on group size, ordering expectations, retention, and whether messages must arrive instantly or can wait.
A USEFUL COMPARISON
Picture it this way
Think of a post office that accepts a letter, records it, routes it to the right destination, and keeps it until delivery is possible. A chat service adds live notifications and may deliver many messages in order. The analogy does not cover encryption, online sessions, or the possibility that clients reconnect and resend requests.
FOLLOW THE JOURNEY
Persist messages before delivering to connected recipients
Trace message submission, durable storage, recipient delivery, and offline recovery.
The exact ordering and acknowledgment contract must be stated. A server accepting a message is not the same as a recipient device receiving or reading it.
A sender submits an authenticated message; the service validates and persists it, queues delivery to recipient devices, tracks acknowledgments, and makes offline messages available on reconnect.
How to read this visual
The exact ordering and acknowledgment contract must be stated. A server accepting a message is not the same as a recipient device receiving or reading it.
UNDER THE HOOD
How it works, step by step
Clarify product guarantees
Define conversations, ordering scope, delivery status, retention, group size, and privacy needs.
Why it matters: These choices change storage, fan-out, and client synchronization.
Accept and persist
Authenticate the sender, validate membership, assign a stable message ID, and durably store the message.
Why it matters: Acknowledging only after persistence reduces loss on service failure.
Deliver and retry
Notify online devices and queue messages for offline recipients with idempotent retry.
Why it matters: Networks disconnect and delivery may happen more than once.
Synchronize state
Track acknowledgments and let clients fetch missed messages after reconnect.
Why it matters: Push notifications alone cannot guarantee a device has complete history.
OUTSIDE THE TEXTBOOK
A practical example
A user sends a message while the recipient is offline. The API checks that the sender belongs to the conversation, stores the message with a unique ID and sequence, then acknowledges acceptance. A notification wakes the recipient when possible; on reconnect, the client requests messages after its last synchronized sequence. Duplicate retries are recognized by the client message ID.
GO A LITTLE DEEPER
Technical details that matter
- At-least-once delivery with idempotent message IDs is often more practical than claiming end-to-end exactly-once delivery.
- Ordering can be guaranteed per conversation with sequence assignment, but global ordering across all conversations is usually unnecessary and expensive.
- Large groups create fan-out trade-offs: write-once/read-many can reduce send work, while per-recipient inboxes can simplify reads.
- End-to-end encryption changes server-side search, moderation, backups, and multi-device synchronization capabilities.
MAKE A GOOD CHOICE
When is this useful?
- Direct and group chat with offline delivery.
- Reliable event or notification systems with recipient acknowledgments.
- Design discussions about persistence, retries, ordering, and fan-out.
For one-way notifications, a managed push service or simpler durable queue may be enough. A full chat system is not justified unless the product requires conversation history, presence, or interactive delivery.
WATCH OUT FOR
Common misunderstandings
- Confusing accepted, delivered, and read states.
- Assuming network retries cannot create duplicate messages.
- Guaranteeing global message order when per-conversation ordering is sufficient.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Push delivery is not guaranteed while devices are offline or operating systems suppress notifications.
- Large groups and multi-device synchronization increase fan-out and state complexity.
- End-to-end encryption limits what servers can inspect or index.
WHAT TO REMEMBER
Key takeaways
- 1Clarify delivery and ordering guarantees before choosing components.
- 2Persist before acknowledging acceptance.
- 3Use stable IDs and idempotent retries for unreliable networks.
- 4Support reconnect synchronization; notifications alone are not a source of truth.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
How would you prevent duplicate messages?
Have clients send a stable idempotency key and make server writes conditional on that key. Clients should also deduplicate during synchronization.
How do you handle ordering?
Assign sequence numbers within a conversation or another explicitly scoped ordering boundary. Avoid promising a global order unless the product requires it.
How would offline delivery work?
Persist messages, notify connected devices when possible, and let clients fetch messages after their last synchronized position when they reconnect.
SAY IT OUT LOUD
How to explain this in an interview
“I would first define whether this is one-to-one or group chat, what “delivered” means, and what ordering and retention users expect. The service authenticates and validates the sender, persists a uniquely identified message, then attempts delivery or queues it for offline recipients. Clients synchronize missed messages on reconnect and deduplicate retries. Group fan-out and end-to-end encryption introduce important trade-offs.”
Connect this question to the roadmap topic it supports.