Most applications start with a single message broker — one Kafka cluster, one RabbitMQ instance, one NATS server. That works fine until the system spans regions, the broker becomes a single point of failure, or different teams need different ordering and durability guarantees. At that point you reach for a topology larger than a single cluster, and the question becomes: what does that topology look like?
The answer is usually an event mesh — a federated set of brokers connected to each other, presenting one logical event surface to producers and consumers. This post is about when to step up from a single event bus to a mesh, and what changes when you do.
What "Event Bus" Means
For the purposes of this discussion, an event bus is a single broker (or a single cluster acting as one) that producers and consumers talk to directly. It has one logical namespace of topics, one set of credentials, one delivery guarantee profile.
Producer A ─┐
Producer B ─┼─► [ Event Bus ] ─► Consumer X
Producer C ─┘ ─► Consumer Y
This is the right architecture for most teams most of the time. One Kafka cluster handles a surprisingly large amount of traffic. The simplicity is worth a lot.
What "Event Mesh" Means
An event mesh is multiple brokers — usually one per region, sometimes one per team — federated together. A producer in one broker can publish an event that a consumer in another broker subscribes to. The mesh moves the events across.
Region US Region EU
Producer ─► [ Bus US ] ◄─►[ Bus EU ] ◄─ Consumer
Region APAC
Consumer ◄─[ Bus APAC ]◄───┘ (federation)
Producers and consumers see a single logical surface — "publish to topic X, subscribe to topic Y" — and the mesh moves bytes between brokers behind the scenes.
The pattern has been called a "global event bus," a "federated event mesh," or just "MirrorMaker-driven Kafka topology" depending on who is writing the slides.
Why You Step Up
A single bus eventually hits one of these walls:
Geography. Producers in Asia and consumers in Europe paying transatlantic latency on every event is expensive and slow. Each region wants a local broker that mirrors to the others.
Failure isolation. A bug or capacity issue in one cluster takes down events for everyone. A mesh contains failures to a single broker.
Regulatory. Some events contain data that cannot cross jurisdictions. A mesh that filters during replication keeps regulated data inside its region.
Team autonomy. A central cluster becomes a coordination point. Each team's schema changes, partition counts, and retention settings have to go through one team. A mesh lets each team run its own broker and only federates the events others need.
Operational scale. A single Kafka cluster handles a lot. At some point — usually north of a few million messages per second — you start considering multiple clusters for operational reasons alone.
The Three Mesh Architectures
Star Topology
One central broker; satellite brokers replicate to and from it. Conceptually simple, has a single point of failure.
[ EU ] ──┐
├─► [ Central ] ◄─ [ APAC ]
[ US ] ──┘
Useful when one region is the source of truth and others are mostly consumers. Less useful when multiple regions originate traffic.
Full Mesh
Every broker replicates to every other. No central authority. High redundancy, higher operational complexity (N² replication paths).
[ EU ] ←──→ [ US ]
↑ ↑
└──→ [ APAC ] ←──┘
Common in multi-region active-active systems. Works well up to a handful of regions; gets unwieldy beyond.
Hierarchical
Brokers are organized in a tree. Leaves replicate to a regional aggregator, regional aggregators replicate to a global aggregator.
[Region US] [Region EU]
│ │
└─►[Global Aggregator]◄─┘
│
┌──────────┴──────────┐
▼ ▼
[Cold Storage] [Analytics Mesh]
Used for analytics fan-in and cross-cutting data products. Lets each tier optimize for its workload.
What Replication Actually Costs
The mesh sounds clean on the diagram. The implementation has sharp edges.
Schema management. Every broker needs the same schema registry, or compatible registries with replication. A schema change has to roll out to all of them safely.
Topic naming and routing. A topic on the EU broker mirrored to the US broker should appear under the same name, or a clear alias. Inconsistent naming is a long-tail debugging nightmare.
Offset translation. A consumer reading from a mirrored topic does not see the original offsets — it sees the mirror's offsets. Tools like Kafka's MirrorMaker 2 try to translate, but corner cases exist.
Loops. A topic that replicates A → B → A creates an event loop if not configured carefully. Production setups need anti-loop protection.
Ordering. Across brokers, global ordering is gone. Within a partition on one broker, ordering is preserved. The mesh as a whole gives you partition-level ordering, not topic-level.
Cost. Cross-region traffic costs money. A mesh that mirrors 10 GB/sec across regions can add five figures to the monthly cloud bill.
Tooling
For Kafka, the dominant tools are MirrorMaker 2 (built into the Kafka project), Confluent Cluster Linking (commercial), and Strimzi (Kubernetes-native).
For NATS, JetStream's source/mirror streams provide built-in federation. NATS leaf nodes are designed for the mesh pattern.
For Pulsar, geo-replication is a first-class feature of the broker.
For RabbitMQ, federation and shovel plugins handle cross-cluster replication, though the operational profile is rougher than Kafka or NATS.
The tooling is no longer the limiting factor. The limiting factor is operational maturity — running one broker well is hard; running a mesh well is harder.
When a Single Bus is Still Right
Step up to a mesh only when one of the walls listed above has actually been hit. Premature mesh architecture is a major time sink. A surprising number of teams that thought they needed a mesh discovered that:
- A bigger single cluster handled the load fine
- Their geographic latency was tolerable
- Their team coordination problems were not actually fixed by a broker per team
The default should be a single cluster, made as redundant and well-operated as needed. Move to a mesh deliberately, when you can articulate which wall you have hit.
Decision Heuristics
| Situation | Architecture |
|---|---|
| Single region, single tenant, low millions of messages/day | Single cluster |
| Single region, multiple tenants, high throughput | Single cluster, careful partitioning |
| Multi-region read replicas, single-region writes | Single cluster + read followers |
| Multi-region active-active | Full mesh |
| Strict regional data residency | Mesh with replication filters |
| Many teams, each with distinct schemas and retention | Federated mesh by team or domain |
The Real Test
The strongest signal that a mesh is justified: producers and consumers in different parts of your system have genuinely different requirements that one broker configuration cannot reasonably satisfy. Different durability, different ordering, different retention, different security boundaries. When one broker is a compromise that hurts everyone, the mesh becomes worth the cost.
Until then, master the single broker. Most of the architectural lessons that matter transfer; a team that runs one Kafka cluster well will run a mesh well. A team that does not should not be standing up a second cluster.
Considering whether your event infrastructure needs to grow beyond a single cluster? We help teams reason through the operational and cost implications before they're locked in. scopeforged.com
