In this post I will discuss the difference between every pattern between Request Response , Message Queues and Publish Subscribe Patterns. I will also discuss the pros and cons and when to use each of them.
Request Response
Request–response or request–reply is one of the basic methods computers use to communicate with each other in a network, in which the first computer sends a request for some data and the second responds to the request. More specifically, it is a message exchange pattern in which a requestor sends a request message to a replier system, which receives and processes the request, ultimately returning a message in response. It is analogous to a telephone call, in which the caller must wait for the recipient to pick up before anything can be discussed. This is a simple but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel; it is especially common in client–server architectures.
This pattern is typically implemented in a purely synchronous fashion, as in web service calls over HTTP, which holds a connection open and waits until the response is delivered or the timeout period expires. However, request–response may also be implemented asynchronously, with a response being returned at some unknown later time.
Pros
1. Stateless (HTTP)
This means that every HTTP request the server receives is independent and does not relate to requests that came prior to it.
2. Scalable
You can scale it horizontally where you can duplicate the receiver or use a load-balancer.
3. Latency
Only when the connection is established, the handshaking process will take place in HTTP. Hence, there will be no handshaking procedure following a request. This significantly reduces latency in the connection.
Cons
1. Administrative Overhead
It is bad for multiple receivers as it causes administrative overhead in the connection.
2. Server Availability
Even if HTTP receives all the data that it needs, clients does not take measures to close the connection. Therefore, during this time period, server will not be present.
3. Integrity
Integrity is not there, so someone can easily alter with the content. HTTP is insecure as there's no encryption methods for it.
Message Queues
A message queue is a form of asynchronous service-to-service communication used in serverless and microservices architectures. Messages are stored on the queue until they are processed and deleted. Each message is processed only once, by a single consumer. Message queues can be used to decouple heavyweight processing, to buffer or batch work, and to smooth spiky workloads.
In modern cloud architecture, applications are decoupled into smaller, independent building blocks that are easier to develop, deploy and maintain. Message queues provide communication and coordination for these distributed applications. Message queues can significantly simplify coding of decoupled applications, while improving performance, reliability and scalability. improving performance, reliability and scalability.
Some of the most popular open-source message queues are Apache
Kafka, RabbitMQ and Celery.
pros
1. Decoupling
If system A sends a message to B, C and other systems, it can send the message through the message queue, and B, C and other systems can get it when used.
2. Asynchronous
System A returns a response after sending a message, waits until B, C and other systems return business data, and then updates the return response, without always displaying the waiting state. Significantly enhance the user experience.
3. Peak cut
When a large number of business needs flood in, direct operations will have a great impact on the database. In order to avoid database downtime, by introducing a message queue, the data to be processed is stored in the message queue until the demand peaks Re-execute the zone, effectively avoiding database downtime and causing system crash.
Cons
1. Increases system complexity
After the introduction of message queues, it is necessary to ensure that there are no issues such as repeated calls and sequence of message delivery.
2. Consistency problem
After the A system is processed, it returns successfully. Everyone thinks that your request is successful; but the problem is that if there are three BCD systems, the two systems BD successfully write the library, and the C system fails to write the library. , Resulting in inconsistencies between the data in the data database and the ideal data.
Pub/Sub Messaging
Publish/subscribe messaging, or pub/sub messaging, is a form of asynchronous service-to-service communication used in serverless and microservices architectures. In a pub/sub model, any message published to a topic is immediately received by all of the subscribers to the topic. Pub/sub messaging can be used to enable event-driven architectures, or to decouple applications in order to increase performance, reliability and scalability.
The Publish Subscribe model allows messages to be broadcast to different parts of a system asynchronously. A sibling to a message queue, a message topic provides a lightweight mechanism to broadcast asynchronous event notifications, and endpoints that allow software components to connect to the topic in order to send and receive those messages.
To broadcast a message, a component called a publisher simply pushes a message to the topic. Unlike message queues, which batch messages until they are retrieved, message topics transfer messages with no or very little queuing, and push them out immediately to all subscribers. All components that subscribe to the topic will receive every message that is broadcast, unless a message filtering policy is set by the subscriber.
Pros
1. Decouple and Scale Independently
Pub/Sub makes software more flexible. Publishers and subscribers are decoupled and work independently from each other, which allows you to develop and scale them independently.
2. Simplify Communication
Communications and integration code is some of the hardest code to write. The Publish Subscribe model reduces complexity by removing all the point-to-point connections with a single connection to a message topic.
3. Scales with Multiple receivers
you can add as many different receivers as you like and scale them smoothly.
Cons
1. Message delivery issues
The broker in a pub/sub system may be designed to deliver messages for a specified time, but then stop attempting delivery, whether or not it has received confirmation of successful receipt of the message by all subscribers. A pub/sub system designed in this way cannot guarantee delivery of messages to any applications that might require such assured delivery.
2. Well-defined Policy
Requires a well-defined policy for message formatting and message exchange; otherwise, message consumption can become mangled and error-prone.
Top comments (0)