Why architecture matters here
The architecture matters because typing events are high-frequency and multiplicative, which makes a careless design a fan-out bomb. Every member of a busy group chat can start and stop typing many times a minute, and each start must be delivered to every other member. In a thousand-member channel, one person typing means one event in but potentially a thousand events out; several people typing at once multiplies that further. Without throttling and coalescing, typing traffic can dwarf actual message traffic and saturate the exact connections your messages need. The architecture exists to keep an inherently chatty signal cheap.
It matters because the failure mode of a naive implementation is a visibly broken UI: the stuck 'typing…' bubble. If clearing the indicator depends solely on receiving an explicit 'stop' event, then any lost stop — a dropped packet, a backgrounded tab, a crashed app, a network drop — leaves the indicator on forever, telling users someone is typing who left minutes ago. Because the signal is best-effort, you cannot rely on the stop arriving; the architecture must clear indicators by expiry, treating the stop as an optimization, not a guarantee.
It matters because typing indicators run on mobile devices where every network wakeup and radio transmission costs battery. A design that sends an event on every keystroke, or that keeps refreshing typing state aggressively, keeps the radio hot and drains batteries for a cosmetic feature. Throttling and sensible TTLs are not just server-cost optimizations; they are directly a battery-life and data-usage decision on the clients your users actually hold.
It matters because the ephemeral nature has to be enforced end to end or it corrupts things it should never touch. If typing events accidentally flow into the same durable, ordered pipeline as messages, they can bloat storage, muddle message ordering, trigger notifications, or show up in history. Keeping typing strictly on a separate, non-persistent, best-effort path is what protects the integrity and cost of the real message system. The separation is the safety mechanism.
Finally it matters because presence and typing are the emotional texture of real-time chat — the difference between a dead inbox and a live conversation. Users read a lot into 'typing…': someone is engaged, a reply is coming, the conversation is two-way. Because it carries social weight, correctness of the feel (prompt appearance, prompt disappearance, no false positives) matters more than the technical 'correctness' of delivery — an architecture tuned for responsiveness and truthfulness beats one tuned for guaranteed delivery of a signal that doesn't need it.
The architecture: every piece explained
The client-side throttle. The client detects typing from input events but does not send one signal per keystroke. Instead it sends a single typing.start when the user begins, then suppresses further starts for a throttle window (commonly a few seconds), sending a refresh only if the user is still typing when the window elapses. It sends typing.stop when the user pauses for a moment, sends the message, or clears the input. This collapses a burst of keystrokes into a trickle of events — the receiver only needs the binary 'actively typing or not,' not the keystroke stream.
The realtime gateway. Typing events ride the same persistent connection as messages — a WebSocket, a long-lived channel, or a managed realtime service — to the gateway that fronts a room or channel. The gateway is the fan-out point: it receives one typing.start and is responsible for delivering it to the other subscribers of that channel. Because the connection already exists for messaging, typing adds no new connection cost, only per-event fan-out cost.
Ephemeral channel state with TTL. The gateway keeps a small in-memory map per channel of who is currently typing, each entry stamped with a time-to-live. A typing.start sets or refreshes the entry with a fresh TTL; the entry is authoritative only for that short window. This state is deliberately not persisted to a database — it lives in memory, is cheap to update at high frequency, and is expected to be lost on restart (at which point clients simply re-announce on their next keypress). It is the opposite of durable message storage.
Fan-out to subscribers. On receiving a typing.start, the gateway pushes a 'user X is typing' event to the other members currently connected to the channel. Large channels apply coalescing and caps: rather than sending each typist individually, the gateway may send an aggregated 'several people are typing' or cap the number of named typists, so a room with hundreds of active typists doesn't generate hundreds of per-typist events to every member. The fan-out policy is where large-room scalability is won or lost.
The three ways it clears. A typing indicator ends via (1) an explicit typing.stop when the user sends or clears input — the fast, common path; (2) TTL expiry when no refresh arrives within the window — the safety net that handles lost stops and crashed clients; or (3) disconnect, when the gateway notices the typist's connection dropped and clears their typing state (and often broadcasts a presence change). Because (2) always runs regardless of (1) and (3), the indicator can never get permanently stuck — the TTL guarantees it.
End-to-end flow
Walk a normal exchange in a group chat. Alice starts typing a reply. Her client detects the first keypress and sends a single typing.start over its existing WebSocket to the channel gateway, then enters a throttle window and stops sending further starts even as she keeps typing.
The gateway receives typing.start from Alice, writes an in-memory entry '{channel: general, user: alice, expires: now+6s}', and fans out a 'alice is typing' event to the other connected members of the channel — Bob and Carol. Their clients render 'Alice is typing…' at the bottom of the conversation. The whole round trip is sub-second, so the indicator feels instant.
Alice keeps typing for fifteen seconds. Her throttle window elapses a couple of times, and each time — because she is still typing — her client sends a fresh typing.start. Each one refreshes the gateway's TTL back to six seconds, so the entry never expires while she is actively typing. Bob and Carol continue to see the indicator, which stays lit as long as the refreshes keep coming.
Alice sends her message. Her client fires a typing.stop and the message itself over the connection. The gateway clears Alice's typing entry immediately on the stop and fans out 'alice stopped typing' so Bob's and Carol's indicators disappear the instant her message arrives — the clean, common path. The message goes down the durable, persisted message pipeline; the typing events do not, leaving no trace in history.
Now the failure path that proves the design. Suppose instead of sending, Alice's phone loses signal mid-sentence — no typing.stop is ever sent, and her connection eventually drops. Bob and Carol should not stare at 'Alice is typing…' forever. Two safety nets fire: the gateway notices Alice's connection dropped and clears her typing state, and even if it somehow didn't, her in-memory entry's TTL expires six seconds after her last refresh, automatically removing her from the typing set and clearing the indicator on Bob's and Carol's screens. The best-effort signal self-heals with no explicit stop.