Realtime Chat Architecture Guide: Presence, Typing Indicators, and Message Sync

Overview

A useful chat system has to solve two different problems at once. First, it has to move ephemeral realtime signals quickly: presence updates, typing indicators, read receipts, and newly sent messages. Second, it has to maintain a durable record that clients can sync from when they reconnect, switch devices, or catch up after being offline.

That split matters because not all chat events deserve the same guarantees. A typing indicator is short-lived and can be dropped with little consequence. A sent message is durable data and usually cannot be lost. Presence sits somewhere in between: it should be fresh, but it also has to recover gracefully when clients disconnect without warning.

A clean realtime chat architecture usually includes these layers:

• Client session layer: mobile, web, or desktop apps maintaining a connection over WebSockets or a similar realtime transport.
• Connection gateway: the websocket platform or edge layer that authenticates users, tracks connected sessions, and receives client events.
• Realtime fanout layer: pub sub architecture for distributing new events to the right users, devices, and rooms.
• Durable message path: message persistence, conversation state, and replay or sync APIs.
• Background processing: message queue solutions for notifications, search indexing, analytics, moderation, and webhook delivery.
• Observability and controls: logs, metrics, traces, rate limits, and backpressure handling.

If you design those layers explicitly, the rest of the decisions become easier. You can decide which events must be persisted, what ordering guarantees are realistic, where deduplication belongs, and how much consistency clients should expect.

One of the most common mistakes in chat app backend design is using one pipeline for everything. Treating message delivery, presence heartbeats, typing indicators, and push notifications as identical events usually creates either unnecessary latency or weak reliability. Separate your flows by business value and required delivery guarantees.

Step-by-step workflow

Use this workflow when designing or refactoring a message sync realtime system. It is intended to be updated as your traffic patterns, tooling, and team size change.

1. Define the event model before choosing tools

Start with a plain-language event inventory. For a typical chat product, you might have:

• Durable events: message created, message edited, message deleted, reaction added, read state updated if it affects history.
• Ephemeral events: typing started, typing stopped, transient presence changes, connection state changes.
• Derived events: push notification requested, unread count changed, moderation flag created, analytics event emitted.

For each event, decide:

• Should it be persisted?
• What ordering matters?
• Is at-least-once delivery acceptable?
• Can clients safely deduplicate it?
• How long is it useful?

This step prevents overengineering. Typing indicators architecture should prioritize freshness and expiration, not perfect delivery. Message sync should prioritize durable storage and deterministic replay.

2. Design conversations as streams of record

For durable chat state, treat each conversation, room, or thread as an append-only stream of message events. That does not require a dedicated event streaming platform, but it does require a clear sequence model.

In practice, each stored message should have:

• a globally unique message ID
• a conversation ID
• a sender ID
• a server-assigned timestamp
• a sequence token or sortable cursor for sync
• delivery metadata if needed

This gives clients a stable way to fetch missed items after reconnect. It also reduces ambiguity when multiple devices race to send or acknowledge events.

If ordering is important within a room, define ordering expectations narrowly. Many systems can maintain useful ordering per conversation without promising perfect global ordering. For a deeper treatment of tradeoffs, see How to Handle Message Ordering in Distributed Systems Without Surprises.

3. Split the write path from the fanout path

When a client sends a message, do not think only in terms of broadcast. Think in terms of authoritative acceptance and then distribution.

A simple and durable flow looks like this:

1. Client sends a message command with a client-generated idempotency key.
2. Gateway authenticates and authorizes the action.
3. Message service validates membership, payload limits, and policy rules.
4. Service writes the accepted message to durable storage.
5. Service emits an event for fanout to active subscribers.
6. Background jobs trigger side effects such as push notifications and indexing.

This order matters. If fanout happens before durable acceptance, reconnecting clients may observe missing messages or inconsistent history. If persistence happens first, the sync API remains the source of truth even when realtime delivery is delayed.

Idempotency is worth adding early. Mobile networks and retry logic will produce duplicate sends. Use client-generated request IDs or server-issued tokens so retries can be safely collapsed. Related guidance: How to Prevent Duplicate Messages in Event-Driven Systems.

4. Build presence as a leased state, not a permanent truth

Presence system design becomes more reliable when "online" is treated as a temporary lease rather than a binary truth. Connections drop. Browsers sleep. Phones lose radio access. A user can be active on several devices at once.

A practical pattern is:

• mark a session online when a connection is established
• renew the session with periodic heartbeats
• expire the session automatically if heartbeats stop
• aggregate session state into user-level presence only if needed

That means presence is inferred from recent evidence, not manually set to false on every disconnect. Manual disconnect handling is still useful, but expiration should be the safety net.

Keep presence payloads small and avoid overpromising precision. "Active recently" is often more defensible than a second-by-second online indicator.

5. Treat typing indicators as expiring hints

Typing indicators architecture should be deliberately lossy. Users only care that the signal feels current. They do not need a permanent audit trail.

Good defaults include:

• publish typing events only to participants in the conversation
• rate limit emissions on the client and server
• set a short TTL so stale indicators disappear automatically
• prefer "typing started" with expiry over complex start/stop synchronization

This reduces network chatter and eliminates many edge cases where the stop event never arrives.

6. Design sync around cursors, not full reloads

Message sync realtime systems usually fail at reconnect boundaries. The fix is to make every client capable of asking a simple question: "What changed after cursor X?"

A resilient sync design often supports:

• initial history load: fetch the latest page for a conversation
• incremental sync: fetch items after the last known cursor
• gap recovery: detect missed ranges and repair them
• multi-device convergence: merge optimistic local state with server-confirmed state

Do not rely on the websocket connection alone as your delivery guarantee. Realtime transport is best seen as a fast path; sync is the correctness path.

7. Define delivery and read state carefully

Chat products often expose states like sent, delivered, and seen. Those labels are easy to misunderstand internally unless you define exactly what each one means.

• Sent: server accepted and stored the message.
• Delivered: at least one intended client session received it, if you support that signal.
• Seen: a user or device explicitly acknowledged reading up to a point.

Avoid letting UI labels imply guarantees your system does not provide. Delivery semantics should follow the capabilities of your transport and storage design, not the other way around.

8. Push non-critical side effects into queues

Search indexing, email alerts, mobile push, compliance archiving, and webhook callbacks should rarely block the user-visible send path. Move them into reliable async processing.

That is where message queue solutions help: they absorb spikes, isolate failure domains, and let chat stay responsive even when integrations are slow. If you are choosing between broker styles, Choosing a Queue for Background Jobs: SQS vs RabbitMQ vs Redis vs Kafka is a useful comparison, and Webhook Queue Integration Patterns: How to Make Unreliable Callbacks Reliable covers a common downstream pattern.

9. Add backpressure and fanout controls early

High-fanout rooms, reconnect storms, and bursts of presence traffic can overwhelm a websocket platform long before message storage becomes the bottleneck.

Plan for:

• connection caps per node or shard
• room membership caching
• batching or coalescing transient events
• slow-consumer detection
• queue depth and publish latency monitoring
• graceful degradation for non-essential signals

If you need a focused guide to websocket scalability, see How to Scale WebSockets: Connection Limits, Fanout, and Backpressure.

10. Secure the connection lifecycle, not just the login

Authentication for chat does not end when a socket opens. Tokens expire, permissions change, and room access may vary by conversation.

A sound pattern includes:

• JWT or session validation at connect time
• authorization checks for every join, publish, or send action
• token refresh or reconnect strategy for long-lived sessions
• server-side enforcement of room membership

For a deeper walkthrough, refer to JWT for WebSockets: Authentication Patterns, Expiry, and Refresh Flows.

Tools and handoffs

The right stack depends on scale, team capacity, and how much operational complexity you can absorb. The important handoff is less about brand names and more about where one responsibility ends and another begins.

Connection and realtime transport

A dedicated realtime messaging API or websocket platform can speed up delivery of chat features, especially for small teams that want managed fanout and connection handling. Self-managed gateways offer more control, but they also require stronger operational discipline around scaling, auth, and failure recovery.

Use this layer for:

• authenticated connections
• room subscription management
• low-latency event fanout
• lightweight ephemeral signals

Do not assume it is also your system of record.

Storage and sync

Your durable store should own conversation history, cursors, and enough metadata for clients to recover from missed events. Whether this is relational, document, or log-oriented matters less than keeping sync semantics clear and query patterns explicit.

Use this layer for:

• message persistence
• history queries
• incremental sync
• read state checkpoints

Pub sub and internal event distribution

Internal pub sub architecture helps decouple write acceptance from downstream consumers. It can be lightweight or built on an event streaming platform, depending on how much retention, replay, and stream processing you need.

Use this layer for:

• fanout to gateways
• analytics and audit pipelines
• notification triggers
• cross-service propagation

If your team is evaluating low-latency broker options, RabbitMQ vs NATS vs Redis Streams: Fast Comparison for Low-Latency Messaging and Kafka Alternatives for Small Teams: Easier Options for Event Streaming can help frame tradeoffs without assuming you need a full Kafka-style stack.

Background jobs and integrations

Queues are often the cleanest place to put side effects that are not required to complete a send. They create clear handoffs between the realtime application and slower systems such as email, mobile push, external webhooks, search, or moderation services.

That separation keeps your chat UX predictable even when dependencies are not.

Quality checks

Before you consider a chat architecture production-ready, test it against failure, duplication, and reconnect scenarios rather than only the happy path.

Correctness checks

• Can a client reconnect and recover all missed durable messages from a cursor?
• Can duplicate send attempts be safely collapsed?
• Are ordering guarantees documented per conversation or event type?
• Can read state move forward monotonically without regressions?
• Do clients know how to reconcile optimistic local messages with server-confirmed records?

Realtime behavior checks

• Do typing indicators expire without explicit stop events?
• Does presence decay automatically when heartbeats stop?
• Can the system drop non-critical ephemeral events under load while preserving message correctness?
• Are reconnect storms handled without cascading failure?

Operational checks

• Do you measure connection counts, publish latency, queue depth, fanout lag, and error rates?
• Can you trace a message from client send to storage to fanout to downstream jobs?
• Do you have alert thresholds for backpressure, failed retries, and growing dead-letter queues?
• Can operators distinguish transport issues from storage issues from downstream integration issues?

If your architecture includes an event streaming platform, the habits in Kafka Observability Checklist: Metrics, Logs, Traces, and Alert Thresholds are broadly useful even beyond Kafka itself.

User experience checks

• Is the UI honest about message state?
• Does offline mode degrade gracefully?
• Do multiple devices converge on the same history without confusing duplicates?
• Are presence indicators useful without implying false precision?

These checks matter because a chat system is judged by edge cases. Users remember missing messages, phantom online states, and typing indicators that never disappear.

When to revisit

Chat architecture should be treated as a living system, not a one-time diagram. Revisit it whenever the product or infrastructure changes enough to invalidate earlier assumptions.

Update your design when:

• you add group chat, threads, or large rooms with very different fanout patterns
• you introduce multi-device sync or offline-first clients
• your websocket platform, broker, or storage tools change
• message volume or concurrent connections grow enough to expose bottlenecks
• security requirements change, especially around JWT refresh, room authorization, or audit needs
• new side effects such as webhooks, search, or AI enrichment enter the send path

A practical review cycle looks like this:

1. List current event types and classify them as durable, ephemeral, or derived.
2. Review whether each type still has the right delivery guarantee and storage path.
3. Trace a reconnect flow from a cold client and note where correctness depends on luck instead of explicit sync.
4. Review observability dashboards for fanout lag, queue growth, duplicate sends, and missed acknowledgements.
5. Run a controlled failure drill: disconnect gateways, delay queues, or force token expiry and observe behavior.
6. Document the decisions that changed so future teams know why the architecture evolved.

If you keep that workflow lightweight and repeatable, your realtime chat architecture can evolve with your product instead of becoming the part everyone is afraid to touch.

The practical rule is simple: messages should be durable, sync should be explicit, presence should expire, typing should be cheap, and side effects should be isolated. If your system follows those principles, you will have a solid foundation for chat features that feel realtime without becoming fragile.