[EVENTING] Channel/Subscription VS Broker/Trigger

Hello Andrey,

Channel and Subscriptions tend to involve a linear flow of events (a "pipeline" of processing), where you end up provisioning a new Channel and Subscription for each stage of processing. At each stage, the generated events are broadcast to all the downstream Subscriptions on the Channel, and there's no "smarts" in the event-transport layer.

Brokers and Triggers implement a routing-based model, where events are fed into a single router per namespace (Broker), and then dispatched intelligently based on the type or other event properties. Putting the routing intelligence into the event-transport layer can help simplify certain event-distribution scenarios:

• Interested in "account.update" events, but don't want to know where they are published? Typically, a single Broker per namespace should be sufficient, and you can simply subscribe by event type.
• Publishing "account.login" events, but not sure where? Again, with a Broker model, you simply publish to a well-known Broker (we suggest calling it "default"), and allow clients to subscribe or not as you wish.

From: knativ...@googlegroups.com <knativ...@googlegroups.com> on behalf of Andrey Stelmashenko <astelm...@viax.io>
Sent: Tuesday, March 15, 2022 9:30 AM
To: Knative Users <knativ...@googlegroups.com>
Subject: [Suspected Spam] [EVENTING] Channel/Subscription VS Broker/Trigger

--
You received this message because you are subscribed to the Google Groups "Knative Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to knative-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/knative-users/103624a3-f206-4cae-b24b-09acce956544n%40googlegroups.com.

Channels are primitive units where you can put any message and subscribers will receive all messages flowing through it. You will mostly see them in scenarios where a single event type goes through it, although that is not mandatory. The imperfect analogy would be a coffee vending machine that will produce coffee to whoever is using it.

Use them when you have a single event type used in a reduced scope.

Brokers correspond to a hub-spoke architecture. You will see them in scenarios where events are put for everyone disposal and it is up to consumers to pick the correct ones. The imperfect analogy would be an airport's baggage carousel, that produces baggage and it is up to users to pick the ones they are interested in.

Use them when you are working at a scope where there are many different event categories and your consumers may vary in time.

It is possible that some of the confusion comes from the fact that brokers might be seen as channels with added filters, but that is an implementation detail. It would be perfectly fine to have a broker implementation that uses no channels (let's say someone builds a broker that abstract Mulesoft or Biztalk).