topicBus
Topic fan-out over PostgreSQL LISTEN/NOTIFY, for telling every running
instance of an app that something happened.
The sibling advisory-lock module is about making sure only ONE connection
does a thing; this one is the opposite - EVERY listening session gets every
notification. That makes it the right primitive for live UI updates
(an SSE stream per browser tab, a cache invalidation, a presence ping) and the
wrong one for work distribution: there are no competing consumers, no acks, and
no replay.
Delivery is best-effort and live. NOTIFY reaches sessions that are listening
at the moment it commits, so a listener that connects a second later never sees
it, and a listener whose connection drops misses everything until the bus
reconnects. Use a table or a queue when a subscriber needs durability.
ONE CHANNEL, MANY TOPICS. Every bus instance listens on a single Postgres
channel (channel, default dbx_tools_topic_bus) and filters by the
envelope’s topic in-process, so adding a topic costs no connection and no
LISTEN. The tradeoff is that every listening session decodes every message on
the channel; give a genuinely high-volume, unrelated stream its own channel
rather than a topic.