Review this design. Every service publishes one event type per aggregate - OrderChanged carries the whole order document plus a changeType string. Eleven consumers subscribe and each begins with a switch on changeType, ignoring types it does not care about. What would you remove, what would you change, and what would you leave alone?

What is actually required

The consumers need to react to specific business facts: payment captured, address changed, order cancelled. What they are given is a notification that something about an order is different, plus the full current document and a hint. The design has moved the routing decision from the producer to all eleven consumers, and duplicated it eleven times.

What I would remove, and why it is safe to

Remove the full document from the event. A fat payload looks convenient and creates three problems: every field becomes a contract with eleven consumers, so no field can be renamed without eleven migrations; events carrying customer data spread that data into eleven stores and every retention and deletion obligation applies to all of them; and the payload invites consumers to read fields they were never meant to depend on, which is how semantic coupling forms invisibly.

Replace it with the fact plus identifiers plus the few fields that define the fact. A consumer that needs more calls back for it, accepting that it will read a state at least as new as the event, which is usually right and must be stated.

Remove the switch statements by splitting the type. OrderCancelled, OrderPaymentCaptured, OrderAddressChanged as separate types let the broker do the filtering. Consumers subscribe to what they need, and the number of messages a consumer processes drops to the ones that concern it, which at eleven consumers and a dozen change types is an order-of-magnitude reduction in wasted work.

The one change that matters

Publish facts, not diffs of a document. An event named for what happened in the business is stable, because the business fact does not change when the storage model does. An event named for a document change is coupled to the document, so every schema change is a breaking change for eleven teams. This single reframing is what makes the rest of the design tractable.

What I would leave alone, even though it looks odd

Leave the eleven consumers. The instinct in review is to say eleven is too many and propose a coordinator. The fan-out is not the problem; the event granularity is. Once events are facts, eleven independent consumers is a healthy shape and precisely what the style buys.

Leave the changeType field in place during migration. Publish both the old fat event and the new fact events for one full retention period, let consumers move one at a time, and delete the old topic when the last one has. A big-bang cutover across eleven teams fails on the slowest team.

How I would argue this in the review

Not on purity. On two numbers: how many teams must change when a field is renamed (eleven today, one to three after), and how much of each consumer's processing is discarded work (typically over 80% with a single fat topic). Then a concrete cost: the one fact that a consumer must never miss, and whether the current design lets them prove they did not.

When not to split the event

When there is exactly one consumer, or when consumers genuinely need the whole document every time, as with a search index or a cache that mirrors the aggregate. A single-consumer topic has no coupling problem to solve, and splitting it is work for no benefit until the second consumer arrives.