The publish-subscribe pattern (or pub/sub, for short) is a messaging pattern where senders of messages (publishers), do not program the messages to be sent directly to specific receivers (subscribers). Instead, the programmer “publishes” messages (events), without any knowledge of any subscribers there may be.
Similarly, subscribers express interest in one or more events and only receive messages that are of interest, without any knowledge of any publishers.
Pub/Sub Message Pattern
KubeMQ supports Publish-Subscribe messages patterns with the following core features:
- Events - An asynchronous real-time Pub/Sub pattern.
- Events Store - An asynchronous Pub/Sub pattern with persistence.
- Grouping - Load balancing of events between subscribers
- Partitioning - Channels/Topics based wildcards
Events are an asynchronous real-time Pub/Sub pattern. In Events, multiple senders can send real-time messages to various receivers; however, only if they are currently connected to KubeMQ; there is no message persistence available in this pattern.
‘Events’ pattern is suitable for cases such as publishing streaming data, logs, notifications, etc.
Events Store is an asynchronous Pub/Sub pattern with persistence. In Events Store, multiple senders can send messages to various receivers even if they are not currently. Any receiver can connect to KubeMQ and replay one, any, or all of the messages stored for a specific channel.
KubeMQ supports six types of Events Store subscriptions and replay:
KubeMQ will send only new events
KubeMQ will replay all events from the first stored events, as well as send new events
KubeMQ will replay the last event and continue to send new events
KubeMQ will replay events from a specific sequence and continue to send new events
KubeMQ will replay events from a specific time in the past and continue to send new events
From Time Delta
KubeMQ will replay events from the particular time delta back (i.e., 5 min back) and continue to send new events
KubeMQ supports grouping (load balancing) of multiple receivers to share the load
The uniqueness of a client ID is essential when using Events Store. At any given time, only one receiver can connect with a unique Client ID. If two receivers try to connect to KubeMQ with the same Client ID, one of them will be rejected.
Client ID and Subscription Types Relations
For each unique Client ID, KubeMQ saves the subscription type in which the client connected; messages can only be replayed once per Client ID and Subscription type.
For example, Receiver with Client ID
client-foo-1subscribes to a channel
First Eventmode. They will get all the messages stored in KubeMQ for
foo.barchannel from the first message, and then continue to get new events as they come. If this receiver will disconnect from KubeMQ and re-connect again with any subscription type, only new events in
foo.barwill be delivered for this specific receiver with Client ID
If a Receiver wishes to receive messages on
foo.baragain, they should subscribe again with a different Client ID than
Events Store pattern is suitable for cases in which events are necessary, such as worker’s pool, chats, and inbox related applications.