Chat System Architecture – System Design

The Architecture Diagram below is intuitive. However, there are several questions which one can ask and the answers to it is given inline.

---

How does instant real-time statuses like online status, typing status, etc shown?

In a real-time chat system, “online status,” “typing status,” and similar live indicators are usually powered by a persistent, bidirectional communication channel—most commonly WebSockets or MQTT—combined with presence tracking on the backend.

Here’s how each part works:

1. Presence Tracking (Online/Offline Status)

• When a user logs in, the client app (web/mobile) opens a WebSocket connection to the server.
• The backend Presence Service records the user’s status as online in a presence database (often an in-memory store like Redis for fast updates).
• When the WebSocket closes (user logs out, loses connection, or goes idle), the backend marks them as offline after a timeout.
  • Redis Hash/Set is common:user_status: { user_id_1: "online", user_id_2: "offline" }
• Push to Other Clients – The presence service broadcasts a status update to all relevant contacts via WebSocket channels or a publish/subscribe system.

2. Typing Indicators

• When a user starts typing, the client sends a “typing” event via WebSocket:{ "type": "typing", "conversation_id": "abc", "user_id": "123" }
• The server receives this event and broadcasts it to all participants in that conversation.
  • Typing status is temporary—after a few seconds with no “typing” events, the client assumes the user stopped typing.

3. Read Receipts & Last Seen

• Read Receipts
  • When a message is displayed on a recipient’s screen, the client sends a “message_read” event to the server.
  • The backend updates the message status in the database and broadcasts to the sender.
• Last Seen
  • Whenever the user’s connection drops or they close the app, the backend records a last_seen timestamp in the database.

4. Protocols Used

• WebSockets – Most common for low-latency updates.
• MQTT – Lightweight alternative, especially for mobile/IoT devices.
• HTTP Fallback – For old browsers, long polling or Server-Sent Events.

5. Security

• Authentication – Every WebSocket connection is authenticated using JWT or OAuth tokens.
• Encryption – TLS for transport security, end-to-end encryption (E2EE) for private messages.
• Event Filtering – A user only receives events for conversations they are part of.

💡 In simple words:
Your online status is updated because the app keeps a “live wire” (WebSocket) connected to the server. The moment something changes—like you start typing—the app sends a tiny signal to the server, and the server instantly pushes that signal to everyone who needs to see it.