Dumb on the way in, rich on the way out

The inbound side is one exchange with a single queue bound to it. No routing, no fan-out, nothing clever. The outbound side is one exchange per business object with routing keys taken from tenant configuration.

• Ordering does not matter to this pipeline, so a single queue with many consumers scales sideways and stays simple.
• The honest trade-off is isolation. One queue means a flood from one module puts every other module's events behind it.
• Exchanges, queues, bindings and routing keys are all declared when the application starts. Adding a new business object is a configuration change, not an infrastructure ticket.

It holds no business knowledge

The pipeline transforms and routes. It does not know what a purchase requisition means, and that is on purpose.

• Deduplication happens in the consuming modules, keyed on their own business ids, because the business meaning belongs to them and not to the plumbing.
• Tenant-specific shapes are handled by pluggable transformers, so a new format is a new class and not a new branch in a growing conditional.
• The result is that the service stays small while the number of object types it carries keeps growing.

Acknowledge last

Consume, look up config, gate, transform, publish, and only then acknowledge. At-least-once, with redelivery when a message is rejected.

• This is the same rule I applied in a different company on a different broker. The queue is a handoff. The durable write is the record.
• It means duplicates are the thing to handle, not loss. That is the trade I want, because a duplicate is recoverable and a lost business object is not.
• The service keeps no state of its own. The broker holds the durability.

Three providers, one internal model

Nothing downstream should know which provider a mail arrived on. That single rule is what makes the rest of the product simple.

• One provider pushes to a webhook, one drops the raw mail in object storage and notifies through a queue, one uses a push subscription. Three completely different failure modes to normalise.
• The mail is written to the database and the raw body to object storage before the provider is acknowledged, so nothing is lost at the edge.
• Deduplication keys off the mail's own message id, which comes from the standard rather than from us. The best idempotency key is usually one the domain already gave you.

Two spam layers, for two reasons

The provider already computes a technical spam score, and it costs nothing to read. So that runs first, at the boundary.

• A cheap model pass then reads the content of whatever survived, because a mail can be technically clean and still be junk.
• The expensive retrieval only runs when an agent asks for it. Cost follows intent instead of volume.
• Suggested replies are shown and then gone. Nothing is stored as a draft, which keeps a model's guess from quietly becoming a record.

A notification platform that stays cheap

Every module in the product publishes into it. That only works if the cost of one notification does not grow with the number of publishers.

• The event carries everything the notification needs. The platform never calls back to ask for missing data, it fails the request. One callback per event would multiply reads across the whole product.
• Templates resolve per channel through a small factory, so adding a channel is adding a class, not editing a dispatcher.
• The email channel routes back out through the provider layer, so there is still only one door to the outside world.

A dual write we did not solve

The provider layer writes the mail to a database and the raw body to object storage. Two writes, no transaction across them. If the second fails, the record and the body disagree. We accepted it, and I can tell you exactly where it bites and what I would do about it.

One queue, no isolation

The single inbound queue is simple and it scales sideways, but it gives one noisy module the ability to slow everyone down. The fix is per-module queues or a prefetch limit, and the cost is a topology that no longer explains itself in one sentence.

A trace that dies at the broker

In an asynchronous system a trace id has to be carried in the message headers, or the story of one event stops at the queue and starts again on the other side as something unrelated. That is the first thing I would add.