Why messaging requires real-time architecture in HLD - Why This Architecture

Problem Statement

When messaging systems do not deliver messages instantly, users experience delays that break the flow of conversation and reduce engagement. Slow or batch message delivery causes confusion, missed responses, and a poor user experience, especially in chat, collaboration, or alerting applications.

Solution

Real-time architecture ensures messages are sent and received immediately by maintaining persistent connections and pushing updates instantly. This approach uses technologies like WebSockets or long polling to keep communication channels open, enabling instant message delivery and live updates without waiting for client requests.

Architecture

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   User A      │──────▶│ Messaging     │──────▶│   User B      │
│ (Client App)  │       │ Server (Real- │       │ (Client App)  │
│               │◀──────│ time Layer)   │◀──────│               │
└───────────────┘       └───────────────┘       └───────────────┘
       ▲                      │  ▲                      ▲
       │                      │  │                      │
       │                      │  │                      │
       └──────────────────────┘  └──────────────────────┘

This diagram shows two users connected through a messaging server that maintains real-time connections to instantly send and receive messages.

Trade-offs

✓ Pros

→

Delivers messages instantly, preserving natural conversation flow.

→

Reduces latency by maintaining persistent connections.

→

Supports live features like typing indicators and read receipts.

→

Improves user engagement and satisfaction.

✗ Cons

→

Requires more server resources to maintain open connections.

→

Increases complexity in handling connection failures and reconnections.

→

May need specialized infrastructure like WebSocket servers or message brokers.

Use real-time architecture when messaging latency must be under a second and user experience depends on immediate feedback, such as chat apps, live collaboration tools, or alerting systems with thousands to millions of concurrent users.

Avoid real-time architecture if message delays of several seconds or minutes are acceptable, or if the system handles mostly asynchronous notifications with low concurrency, where simpler polling or batch delivery suffices.

Real World Examples

WhatsApp

Uses real-time messaging architecture with persistent connections to deliver instant chat messages and presence updates worldwide.

Slack

Implements WebSocket-based real-time messaging to enable live chat, typing indicators, and immediate notifications in team collaboration.

Uber

Uses real-time messaging to update drivers and riders instantly about trip status and location changes.

Alternatives

Polling

Clients repeatedly request the server for new messages at intervals instead of maintaining open connections.

Use when: Choose polling when real-time speed is not critical and system simplicity or compatibility with older clients is prioritized.

Long Polling

Clients send a request that the server holds open until new data is available, then responds, simulating real-time without persistent connections.

Use when: Use long polling when WebSocket support is unavailable but near real-time updates are still needed.

Summary

Messaging systems need real-time architecture to avoid delays that disrupt conversations.

Real-time architecture uses persistent connections to push messages instantly between users.

This approach improves user experience but requires more complex infrastructure and resource management.