System 12.9 — Chat System
In one line
WebSocket gateways, message ordering per conversation, presence, and 'what if the client reconnects'.
Think of it like this
WhatsApp's basic skeleton: getting a message from your phone to your friend's phone in real time, and making sure it's still there waiting for them even if their phone was switched off when you sent it.
Key ideas
- 01
Transport choice: WebSocket for live messages; REST for history/upload; presence via WS presence channel; (SSE for a one-way variant).
- 02
Components: WS gateway fleet (stateful connections), chat service, message store (wide-column: partition=conversationId), presence service, push (FCM/APNs when offline).
- 03
Ordering: sequence numbers per (conversation, sender); per-conversation single writer per message append or rely on DB auto-id + client sort.
- 04
Scale: 10M users, 100 msg/s avg; WS connections = memory + sticky LB or coordinated gateway (consistency: route by conversation shard).
- 05
Reconnect story: client resumes with last-received seq; server returns only newer messages (idempotent catch-up).
- 06
Delivery: at-least-once over WS + client dedupe by msgId — exactly-once is client-side.
- 07
Consistency/per-sender: messages are ordered per conversation; across conversations no ordering exists — the honest contract.
- 08
Presence: heartbeat + expired-by-TTL timestamps → 'online/last seen' — a separate small datastore.
Java / Spring map
- →
Spring WebSocket + STOMP; message store in Cassandra (partition key conversationId, clustering ts/guid).
Code & diagrams
The core loop: a persistent connection per user, a router that finds where they're connected, and a durable store so offline delivery still works.
Explain without notes
A device drops mid-message. Walk reconnect: what the client sends and the server returns — and how dupes are killed.
Practice
Design the message table (partition key, clustering, TTL) and the WS gateway scaling with connection routing.
Trade-offs
- ↔
Single-partition ordering vs throughput — conversations are inherently per-order; that's fine.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can present chat end-to-end: WS gateways, per-conversation ordering, catch-up, presence, push fallback.