How do typing indicators work in a messaging app?

When a user begins typing, the client sends a typing-start event to the server, which forwards it via WebSocket or Server-Sent Events to other participants in the conversation. If the server does not receive a subsequent typing-continue event within a short timeout (typically 3-5 seconds), it automatically broadcasts a typing-stop event. This approach minimizes the risk of a stuck 'is typing' indicator if the client disconnects unexpectedly.

What are the main challenges when designing a typing indicator system?

The main challenges include minimizing latency so indicators appear in near real time, avoiding high write amplification from frequent keystroke events (solved by throttling or debouncing client-side signals), handling stale indicators when a user stops typing without sending an explicit stop event (solved with server-side TTLs), and scaling fan-out in large group conversations where one user's typing event must reach many recipients efficiently.

Should typing indicators use WebSockets or polling?

WebSockets are strongly preferred for typing indicators because they provide full-duplex, low-latency communication over a persistent connection. Polling introduces unnecessary latency and server load — since typing events are ephemeral and time-sensitive, a 1-2 second polling interval would make the indicator feel laggy, while shorter intervals would create excessive HTTP overhead. Long polling is a reasonable fallback when WebSockets are unavailable.

How do companies like Slack and WhatsApp implement typing indicators?

Most large messaging platforms use persistent WebSocket connections to relay typing events between clients through presence or messaging servers. Clients throttle typing signals to one event per second or so rather than sending a signal on every keystroke. The server maintains a short TTL (often 5-10 seconds) on typing state, automatically clearing the indicator if no refresh arrives. In group chats, fan-out is handled via pub/sub channels scoped to the conversation ID.

Low Level Design: Typing Indicators Service

⏱ 4 min read

What Is a Typing Indicators Service?

A typing indicators service detects when a user is actively composing a message and broadcasts that signal to other participants in the same conversation. It is a real-time, ephemeral feature seen in chat apps like WhatsApp, Slack, and iMessage. The challenge is delivering low-latency signals without overloading the server with a keypress-per-event stream.

Data Model

Typing state is purely ephemeral. No durable database is needed; Redis alone is sufficient.

Redis Key Patterns

typing:{conversation_id}:{user_id}   STRING   value = 1, TTL = 5s
typing:{conversation_id}             SET      members = { user_id, ... }  (active typists)

Event Schema (Kafka / WebSocket message)

{
  event:           typing_start | typing_stop,
  conversation_id: STRING,
  user_id:         BIGINT,
  timestamp_ms:    INT64
}

Core Algorithm: Debounce and TTL

The client does not send an event on every keystroke. Instead it uses a debounce strategy:

First keystroke: Client emits a typing_start event immediately.
Subsequent keystrokes: Client resets a 3-second idle timer but sends no additional events.
Idle timeout: If the user stops typing for 3 seconds the client emits typing_stop.
Server TTL safety net: The server sets SET typing:{conversation_id}:{user_id} 1 EX 5 on each typing_start. Even if the client disconnects without sending typing_stop, Redis expires the key after 5 seconds, automatically clearing the indicator.

Fanout Workflow

The API gateway receives the typed event over WebSocket and publishes it to Kafka topic typing.events.
A fanout service reads from the topic, looks up all online participants in the conversation, and filters out the sender.
For each recipient the fanout service publishes a push notification to the recipient's gateway node using an internal channel (notify:{user_id}).
The recipient's gateway delivers the typing_start or typing_stop event over the open WebSocket.

Failure Handling

Client disconnect: The Redis TTL (5 s) clears the typing flag automatically. Recipients see the indicator disappear within 5 seconds at most.
Gateway crash: The client reconnects, re-registers presence, and reissues typing_start if still composing. Stale Redis keys expire on their own TTL.
Kafka lag: Typing events are low-priority and can be dropped during extreme lag using a short retention policy (e.g., 60 seconds). Stale indicators self-correct via TTL expiry.
Redis node failure: With Redis Cluster, the affected shard's keys are unavailable briefly. Typing indicators disappear for users hashed to that shard until the shard recovers or is replaced.

Scalability Considerations

Typing indicators are high-frequency but tiny. The main concerns are fan-in write volume and fan-out delivery latency.

Debounce on client: Reduces upstream event rate from ~10 events/second per user to roughly 1 event per 3 seconds. This single optimization cuts server load by an order of magnitude.
Coalesce in the fanout service: Batch multiple typing events for the same conversation within a 100 ms window before delivering to recipients.
Group chat scaling: For large group conversations (1,000+ members) limit typing indicator fanout to the visible participant list in the client's viewport. Server-side, cap fanout at 200 recipients per event.
Stateless services: Gateway and fanout nodes hold no local state. Horizontal scaling is straightforward behind a load balancer.

Summary

A typing indicators service is a lightweight but latency-sensitive component. Client-side debouncing and server-side TTL-based expiry together eliminate the two main failure modes: event storms from rapid keystrokes and stuck indicators from abrupt disconnects. Redis ephemeral keys, Kafka for reliable fanout, and stateless gateway nodes give the system the headroom to scale to millions of concurrent conversations.