Use cases

Why people pick FastPubSub

Low latency. Cross-region reach. Fastest-path routing. Firewalls and DPI are less likely to eat the session.

Online-only fanout. No persistence. Ephemeral signals. That is the product.

Typical topologies

• 1→N (broadcast) — One writer, many listeners. Prices, scores, game state.
• N→N (rooms) — Many writers, many listeners on the same channel. Chat rooms, collaborative sessions.
• N→1 (telemetry uplink) — Many writers, one listener. Sensor data, metrics aggregation, control plane feedback.

Workloads that fit

Live data. Push frequent updates (prices, scores, sensors) to many subscribers. One channel per stream. Many listeners subscribe.

Games. Events or state with low latency. Often one writer (game server) and many listeners (players). Sometimes several writers for region shards.

Chat and signals. One channel per room or topic. Writers and listeners share the tenant and channel. The service fans out to everyone subscribed.

Other patterns that work

Control plane / edge coordination. Config updates, feature toggles, cache invalidation between your services and globally scattered nodes. Latency beats persistence here.

Presence and live status. Lightweight online/offline or health pings. Only the latest state matters. Missed history is fine.

Event notifications. Ephemeral pokes to browsers and phones. You do not run a global WebSocket fleet of your own.

Market data / ticks. Tiny messages, high rate, many subscribers. Quotes, book deltas, live odds. Latest state. Not history.

Live collaboration signals. Typing indicators, cursor presence, “user is editing” beacons, whiteboard pings. Ephemeral. Do not store this.

Realtime matching / rendezvous. Swap short offers/answers and metadata, then jump to a direct media or data path.

Progress of long jobs. Push “10%…20%…done” from workers to dashboards. No polling. Losing a middle tick is fine if the latest one lands.

IoT alarms. “Temperature > X”, “door opened”, to several listeners, fast. The transport does not need to keep every signal.

Multi-region failover signaling. Fast “drain traffic”, leader-change, failover pokes to services in several regions during an incident.

Channel design tips

• Use stable channel roots (namespaces). Keep payloads small. One overlay message is ≤64 KB. Larger application data can use the SDK FragmentFilter.
• Use tenants for environment/customer isolation (see Using tenants).
• Keep names descriptive and consistent: orders.created, game.room.123, sensors.eu.temp.
• Reserve separate roots for public vs internal traffic (example: pub.# for client-facing events, sys.# for internal control).
• Prefer a consistent event naming scheme (event type last: orders.123.created, orders.123.updated).
• Version the event schema when payloads may change: v1.orders.# (or orders.v1.#).
• Avoid unbounded channel cardinality (a unique channel per message). Prefer per-room / per-match / per-stream channels.

Channel patterns

All examples below use only exact names or the .# suffix (the only wildcard allowed in tokens).

• Sharded streams (load distribution) — split a hot stream into a fixed number of shards: orders.shard.00.# … orders.shard.63.# (writer picks shard by hash of id).

• Entity tree (object-centric channels) — “everything about an object” and “everything about a type”: entity.user.123.#, entity.user.# (events: entity.user.123.profile.updated).

• Command / event split — separate commands, events, and system signals into different roots: cmd.game.42.#, evt.game.42.#, sys.game.42.#.

• Region-first naming — geography in the first segments for convenient prefix subscriptions: geo.eu.de.by.munich.#; subscriptions: geo.eu.#, geo.eu.de.#.

• Room partitioning — split large rooms by traffic type: room.123.msg.#, room.123.presence.#, room.123.typing.#.

• Latest-state channels — statuses where only the last update matters: status.user.123.online, status.service.api.latency.p50 + subscription status.user.#.

• Session / rendezvous channels — short-lived sessions and participant coordination: session.abc123.#, matchmaking.queue.eu.#, matchmaking.match.42.#.

• Public vs internal roots (capability boundaries) — so permissions are readable at a glance: pub.myapp.# (client-facing), sys.myapp.# (internal control), priv.user.123.# (per-user).

• Schema versioning in the prefix — safe payload evolution: v1.orders.# → later v2.orders.#.

• Gaming proximity (AOI) — cells/geohash, subscribe to neighbors: game.42.cell.u33dc.# (client holds 9–25 subscriptions and updates them as it moves).

FastPubSub routes along the fastest available measured paths. That can beat default Internet routes. It also behaves better on networks with fussy policies.

See the Use cases section in the sidebar for step-by-step examples.