Learning about Reactive Messaging Patterns

Learning about Reactive Messaging Patterns

Message-driven systems are those that communicate primarily through asynchronous and non-blocking messages. Messages enable us to build systems that are both resilient, and elastic, and therefore responsive under a variety of situations.

According to the Reactive Manifesto, a critical element in any Reactive system is that it is message-driven. But what does it mean to be message-driven?

Message-driven systems are those that communicate primarily through asynchronous and non-blocking messages. Messages enable us to build systems that are both resilient, and elastic, and therefore responsive under a variety of situations.

Message Driven Architecture

We have various ways of accomplishing synchronous and asynchronous messaging. But when we try to use synchronous messages to accomplish the task where an asynchronous message is required or vice-versa, things break down. Thus we need to make sure that we’re using the right tool for the job.

Usage of Asynchronous Messaging

Asynchronous messaging is used when the messages can be sent without waiting for a response. It is used to avoid the situation where two parts of the system are waiting on each other, and consuming resources the entire time. Using asynchronous and non-blocking messages, resources like threads, memory, etc. can be freed immediately, and contention is reduced, which in turn improves scalability. It provides a higher rate of reliability because messages can be queued for delivery in case the receiver is off-line. It also allows us to have portions of the system go off-line for sometimes, and have the remainder of the system to continue to operate as normal.

Cost of Asynchronous Messaging

Asynchronous messages make transactions more difficult because transaction remains open potentially for a long period, which makes systems very slow and brittle. Using transactions that cross micro-service boundaries should be avoided because, some services may be unavailable, or multiple databases may be involved, and long-running transactions increase contention.

Usage of Synchronous Messaging

Asynchronous messages should be the backbone of Reactive Systems. To achieve this, synchronous messages can also be used but their requirements can often be relaxed. So rather than sending a message and waiting for a response, we might just send a message and have the receiver acknowledge that they received the message.

Cost of Synchronous Messaging

Technically it’s often very convenient to build using fully synchronous messages. But there are costs associated with it. Those costs show up in the forms of inability to scale and reduced reliability.

So our goal should be to understand the difference between synchronous and asynchronous messaging and the consequences of choosing between the two.

Guaranteeing Delivery of Messages

As we build out our distributed systems, we are forced to confront the reality that delivering messages in a distributed system is complicated. We need to be careful to ensure guaranteed delivery of messages, that means, a message should be delivered to the correct recipient, the expected number of times. To provide these guarantees, we need new tools and techniques.

At Most Once Delivery

At Most Once delivery promises that no message will ever be delivered more than once. If a failure occurs, message delivery is never retried, which means that messages are never duplicated, but they could be lost. The advantage of this delivery technique is that it is very easy to implement, and does not require the storage of messages.

At Least Once Delivery

At Least Once delivery guarantees that all messages will eventually be delivered. When a failure occurs, there are two possibilities. One possibility is that the message may not have been delivered. The other possibility is that the message may have been delivered but not acknowledged. Failure always results in a retry, which means that messages may be delivered more than once, but they’re never lost. This delivery technique requires the storage of messages at the sender’s side.

akka microservices reactive architecture tech blogs #messagingpatterns #microservices #reactivearchitecture #reactiveprogramming #reactivesystem

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Diving Into Reactive Microservices

What Happens When Reactive Meets Microservices? It would be beneficial if you understand the concepts of Reactive Architecture before diving into Reacti

Serverless Vs Microservices Architecture - A Deep Dive

Companies need to be thinking long-term before even starting a software development project. These needs are solved at the level of architecture: business owners want to assure agility, scalability, and performance.

Wondering how to upgrade your skills in the pandemic? Here's a simple way you can do it.

Corona Virus Pandemic has brought the world to a standstill. Countries are on a major lockdown. Schools, colleges, theatres, gym, clubs, and all other public

Diving Into Reactive Microservices

What happens when reactive meets microservices? In this article, we will cover the transition from Monoliths to Service Oriented Architecture to Reactive Microservices by applying isolation techniques to the application.

The Service Mesh in the Microservices World - DZone Microservices

In this article, take a look at the service mesh in the microservices world. The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.