[EVENTING] Channel/Subscription VS Broker/Trigger

224 views
Skip to first unread message

Andrey Stelmashenko

unread,
Mar 15, 2022, 12:30:20 PM3/15/22
to Knative Users
It is possible to create channel and subscriptions to connect producer and consumer. It is also possible to use Broker and Trigger to achieve the same. Could somebody please clarify and recommend when to use Channel/Subscription and when use Borker/Triggers.

Evan Anderson

unread,
Mar 15, 2022, 1:11:32 PM3/15/22
to Andrey Stelmashenko, Knative Users
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.

For basic scenarios, we suggest using Broker & Trigger; Channel and Subscription are available for more advanced use cases like processing pipelines where you only want to trigger on events from a specific upstream source.

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
 
It is possible to create channel and subscriptions to connect producer and consumer. It is also possible to use Broker and Trigger to achieve the same. Could somebody please clarify and recommend when to use Channel/Subscription and when use Borker/Triggers.

--
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.

Andrey Stelmashenko

unread,
Mar 16, 2022, 4:51:11 AM3/16/22
to Knative Users
Thank you, I had similar thoughts, I'm glad to hear about semantics from somebody else to confirm.

wenfeng wang

unread,
Mar 23, 2022, 10:11:32 PM3/23/22
to Andrey Stelmashenko, ev...@vmware.com, Knative Users
I have the same confusion. I know what I should use in different scenarios, but I still don't understand why Knative Eventing has separated them into two different concepts. In my view, the channel and subscription actually is a special case of broker and trigger without a filter. I'd very much appreciate it if anybody let me know it!

Andrey Stelmashenko <astelm...@viax.io> 于2022年3月16日周三 16:51写道:

Pablo Mercado

unread,
Mar 24, 2022, 3:20:33 AM3/24/22
to wenfeng wang, Andrey Stelmashenko, ev...@vmware.com, Knative Users
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).



Reply all
Reply to author
Forward
0 new messages