Channel naming
Channel naming is a product decision. Good naming makes:
- permissions readable,
- troubleshooting faster,
- scaling and sharding easier.
This page lists conventions that work well in production.
Use dot-separated segments
Use dots (.) to build a hierarchy:
- Good:
orders.eu.created,sports.football.live,device.sensor-01.temp
This matches how subscription patterns work.
Make roots represent capabilities
Pick stable roots and separate “public” and “internal” traffic:
pub.<app>.#— client-facing eventssys.<app>.#— internal control plane signalspriv.user.<id>.#— per-user private streams
If you do this, token permissions become easy to understand at a glance.
Version your payload schema
If payload formats may evolve, include a version segment:
v1.orders.#- later
v2.orders.#
This prevents accidental breakage when old and new clients coexist.
Avoid unbounded channel cardinality
Avoid a new unique channel per message. Prefer “room / stream / entity” channels:
- Good:
room.123.msg.# - Risky:
msg.<random-id>(unbounded)
If you need per-entity streams, use a controlled id space and apply limits.
Plan for sharding when needed
For hot streams, shard into a fixed number of channels:
orders.shard.00.#…orders.shard.63.#
Writers pick a shard by hashing an id, and listeners subscribe to the shard set they need.