advanced 2 min answer Multiple choice

An ecosystem of many business lines needs to share data and events. Should integration be point-to-point, through a central hub, or event-driven? What decides it?

integrationhubeventscouplingtencentwechatarchitecture-selection
Pick one
Show the full answer Hide the answer

The decisive distinction

Whether the interaction carries an obligation or states a fact.

Notifications — "order placed", "user registered", "content published" — state a fact. The publisher does not care who consumes them. These belong on event streams with published, versioned contracts, so consumers can be added without touching the publisher.

Commands — "reserve this", "charge that", "provision this account" — carry an obligation with an expected effect and someone responsible. These need a direct call or an orchestrated workflow with an owner, an acknowledgement and a timeout.

Confusing them causes the two characteristic failures: a command treated as a notification produces work that silently does not happen with no owner and no retry policy; a notification treated as a command couples the publisher's availability to every optional consumer.

Why not point-to-point everywhere

It works until the connection count grows. Each new consumer requires the producer to change, contracts are implicit and undocumented, and nobody can enumerate what depends on what — so no producer can safely change anything.

Why not everything through a hub

A central hub becomes a bottleneck for change and a correlated failure domain. Worse, hubs accumulate transformation and business logic that belongs in the domains, becoming a distributed monolith every team must change and nobody owns.

Hubs are justified for genuine mediation: protocol translation for legacy systems, partner-facing integration where an anti-corruption layer is needed, and centralised policy enforcement for external traffic.

What makes the event approach work at ecosystem scale

  • A schema registry enforcing compatibility as a build gate, so a breaking change fails the producer's build rather than a consumer's overnight batch.
  • Events treated as public APIs, with versioning, deprecation and consumer measurement — because once an event has external consumers, that is what it is.
  • Clear data ownership. One system of record per entity, publishing changes; everyone else consuming. Without this, several systems publish contradictory versions of the same fact.
  • Per-consumer isolation, so a slow consumer cannot affect the producer or other consumers.

The governance that matters most

Ownership per entity and per event stream. In most large enterprises the dominant integration problem is not the transport; it is that nobody can say which system is authoritative for the customer record — and no integration pattern fixes that.