Thread by @tpierrain

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum @ygrenzinger Let me clarify then ;-)
Thread ⬇️

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum 1. Request-Reply (in the context of a message bus):
when a client is asking something to an abstracted service (via topic/queue). The indirection abstraction allows you to scale out the number of process that are able to provide answers on behalf of the service/topic.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum If you are using a hub and spoke architecture implementation (aka. Broker base), it also allows you to receive requests from any client even when no one is able to provide an answer when the request arrive.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum All you have to do is to keep your intermediary (clustered message broker) ready to receive and keep messages. This implies asynchronous messaging interactions of course.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum Guaranteed delivery option is ensured with ack-based mechanisms.

First: when the broker ack the client that it has received its message (“your message won’t be lost”).

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum Secondly: when the service/queue consuming agent ack the messaging broker that it has processed/done whatever needs to be done with this message/request (“this message has been processed, you can now remove it from the broker/queue).

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum Request-Reply is a 1-to-(big)1 interaction

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum 2. Publish-Subscribe :

when one or multiple publishers want to fan-out a message to multiple consumers. The publisher is usually not aware of its subscribers. It does not know who they are and how many they are.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum The indirection is often a topic and a multicast address (for a UDP multicast network-based solution) or a topic and a broker address (for a TCP or UDP unicast broker-based solution).

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum The fan-out delivery of the message to a huge set of subscribers may raise latency fairness issues if it is done by software (i.e. a messaging broker). Indeed, the last subscriber of the list will receive the message long time after comparing to the first subscriber of the list.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum This is where multicast network-based solutions are far better (fan-out distribution being made with hardware/appliances/switch etc). If a subscriber subscribes to a topic after a message has been sent on, it will usually not catch-up it.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum 3. Request-ReplyWithInterest :

A stream-based with “sorry I’m late, can you remind me the state of the world first and then keeping me updated of any further change” subscription messaging pattern.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum Usually, the messaging solution following that pattern caches somewhere the state of consumption of its various clients (client-lib-level, intermediaries, proxies etc.)

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum The publisher (source) is aware of its clients and their state but smart implementations are caching all of them to the source with intermediaries.

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum Whereas Request-Reply is a 1-to-(big and available)1 pattern

Pub-Sub and Request-Reply-with-interest are 1-to-many

These are 3 major messaging patterns that you can implement in so many (complex) ways depending on your context, ecosystem, network, etc

Focus on the usages first

@_dupdob_ @ygrenzinger @Nils_Back @riduidel @Ouelcum Again, no silver bullet on that topic too. Only nice enough trade-offs to find depending on our context.