[Eventing] Broadcasting events to services

52 views
Skip to first unread message

Andrey Stelmashenko

unread,
Oct 6, 2021, 9:36:50 AM10/6/21
to Knative Users
Hi, Community,

I have a use case which I'd like discuss with you.
We are designing Subscriptions support. Client App (Browser) should be able to receive messages from server side. As event source to trigger message push to client browser we are considering entities update channel. To implement subscriptions we can choose e.g. WebSockets (WS) technology. The specifics of WS is that connection is created from a specific instance on server side. And server side instances of the service which opens connection is behind load balancer. Knative channels using 'push' to url, so we do not know which instance message will go.
For that task we need broadcast events to all instances of that service (WS connection owner).
Possible ways to do that is to subscribe to underlying message channel (we are using nats), so events are published to kn-channel and knowing name of nats channel behing kn channel we can subscribe.
Another way is to add a proxy function which will be getting services pods and broadcast to them cloudevents directly.

May be you considered such use cases and have something elegant to solve the problem?

Evan Anderson

unread,
Oct 6, 2021, 10:15:07 AM10/6/21
to Andrey Stelmashenko, Knative Users
Hey Andrey,

You're right that the push semantics of Knative Eventing aren't really a great fit for your "broadcast to all nodes" use-case. I'd recommend using NATS (or some other broadcast tool, like Kafka without a consumer group or a watch API) directly for this use case; one reusable component which could be built would be a NATS-publish "sink" which transformed CloudEvents into natively published NATS messages.

To clarify a bit for the curious, Knative Eventing's model could probably best be described as "infrastructure-assisted competing consumers". This is a model that works well for the core use case of routing events between application components as a messaging bus (like in a FaaS), but there are other models that Eventing doesn't cover at the moment. A few high level patterns that Eventing doesn't currently cover:

Time-ordered partitioned data streams (stream processing)
State-tracking associated with object changes (workflows)
Backlog-focused event tracking (work queues)
All-instances state notification (broadcast)


--
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/24054c79-0bae-4226-8824-1d22ce13d2a0n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages