3 Messaging Patterns — to never fail coding interview
Cloud applications are distributed, a messaging infrastructure is required to connect the components and services, ideally in a loosely coupled manner to optimize scalability. Asynchronous messaging is widely used and has many advantages, but it also poses problems such as message ordering, poison message management, idempotency, and others.
Introducing you to messaging design patterns that will change the way you orchestrate your applications. I will try to provide issues, the best use cases for using such patterns, and scenarios when not to use them.
Asynchronous Request Replay Pattern
Client applications—generally code running in a web-client (browser)—rely on remote APIs to supply business logic and combine functionality in modern application development. These APIs may be directly tied to the application or third-party shared services. These API requests are typically made using the HTTP(S) protocol and adhere to REST semantics.
HTTP polling is one solution to this problem. Client-side code can benefit from polling because it can be difficult to provide call-back endpoints or leverage long-running connections. Even when callbacks are possible, the additional libraries and services necessary can occasionally add undue complexity.
- The client application sends a synchronous request to the API, which initiates a long-running action on the backend.
- The API reacts as rapidly as feasible in synchronous mode. It returns an HTTP 202 (Accepted) response code, indicating that the request has been received and is being processed.
- The response contains a location reference pointing to an endpoint that the client can poll to see the outcome of the lengthy operation.
- Processing is offloaded to another component, such as a message queue, through the API.
- It returns HTTP 200 for each successful call to the status endpoint. The status endpoint provides a resource indicating that the task is still in progress while it is still pending. When the task is finished, the status endpoint can either return a completion resource or redirect to another resource URL. If the asynchronous activity, for example, produces a new resource, the status endpoint will redirect to the URL for that resource.
Useful for?
- Client-side code, such as browser apps, where providing call-back endpoints is problematic because the use of long-running connections adds too much complexity.
- Service calls where only the HTTP protocol is accessible and the return service is unable to trigger callbacks due to client-side firewall constraints.
- Service calls that must be integrated with legacy architectures that lack current callback technologies such as WebSockets or webhooks.
Not so great for?
- Responses must be delivered to the client in real time.
- The client must collect a large number of results, and the received latency of those results is critical. Instead, consider a service bus pattern.
- Server-side persistent network connections, such as WebSockets or SignalR, can be used. These services can be used to inform the caller of the outcome.
- You can use the network design to open ports to receive asynchronous callbacks or webhooks.
Publisher-Subscriber pattern
Create an asynchronous messaging subsystem that includes the following components:
The sender’s input messaging channel. The sender packages events into messages and sends them via the input channel using a specified message format. In this design, the sender is also known as the publisher.
Each consumer has one output message channel. Customers are referred to as "subscribers."
A system for replicating each message from the input channel to all subscribers who are interested in that message. Typically, an intermediary such as a message broker or event bus handles this activity.
The logical components of this pattern are depicted in the image below:
Issues:
- Subscription handling: Consumers must be able to subscribe to and unsubscribe from various channels through the messaging infrastructure.
- Security: To avoid eavesdropping by unauthorised users or applications, connecting to any communication channel must be controlled by security policy.
Useful for?
- An application must broadcast information to a large number of users.
- An application must interact with one or more independently produced applications or services, which may use various platforms, programming languages, and communication protocols.
- An application can convey information to users without forcing them to respond in real time.
- The interconnected systems are intended to provide an ultimate consistency model for their data.
- An application must deliver data to several consumers, each of whom may have different availability requirements or uptime schedules than the sender.
Not so great for?
- An application has only a few consumers who require information that is notably different from that required by the producing application.
- An application necessitates near-real-time contact with users.
Competing Consumers pattern
A cloud-based application is anticipated to manage a huge number of requests. Instead of processing each request synchronously, it is typical for the application to route them through a message system to another service (a consumer service) that handles them asynchronously. This method helps to ensure that the application’s business logic is not slowed down while the requests are being processed.
For a variety of reasons, the quantity of requests can fluctuate dramatically over time. A surge in user activity or aggregated requests from numerous tenants can result in unanticipated demand. During peak hours, a system may need to process hundreds of requests per second, yet at other times, the number may be quite low. Furthermore, the type of work conducted to respond to these requests may be quite diverse. You can cause a single instance of the consumer service to become swamped with requests if you use it. Alternatively, an inflow of messages from the program could overburden the messaging system.
The system can operate numerous instances of the consumer service to meet the varying workload. These customers, however, must be coordinated such that each message is only provided to a single consumer. To avoid one instance from becoming a bottleneck, the workload must also be distributed among consumers.
Solution:
To implement the communication channel between the application and the consumer service instances, use a message queue. The application sends messages containing requests to the queue, and the consumer service instances receive and process the messages. This method allows the same pool of consumer service instances to handle messages from any application instance. The diagram depicts the use of a message queue to distribute work to service instances.
Issues:
- Message Ordering: The order in which messages are received by consumer service instances is not guaranteed and does not always correspond to the order in which the messages were created.
- Detecting poison messages: A service instance can fail due to a faulty message or a task that requires access to resources that aren’t available.
Useful for?
- An application’s workload is separated into jobs that can run asynchronously.
- Tasks are self-contained and can operate in parallel.
- The job volume is very changeable, necessitating a scalable solution.
- The solution must be highly available and resilient in the event that task processing fails.
Not so great for?
- It is difficult to divide the application burden into discrete tasks, or there is a high degree of dependability between tasks.
- Tasks must be completed in a synchronous manner, and the application logic must wait for a task to complete before proceeding.
- Tasks must be completed in a specified order.
One clap, two clap, three clap. Forty?
Thanks for reading. If you get any valuable information from this article, then feel free to comment and follow for more content. Believe me, no clap or follow, goes unnoticed.
This is part two of the “Cloud Patterns” series; please read the first blog article, in which I attempted to describe 7 architectural patterns.
I have used all of these patterns while working in my company, so I know they will come in handy not only for interviews but also when you join your dream company.
Are you seeking a new job? Does your resume measure up? Check out my blog post on the use of AI tools for the entire job search process, from employment search to salary negotiations.
Are you afraid of d̵a̵r̵k̵ Releases? Check out my next blog explaining feature flags, here.
Keep Hustling, Keep Dreaming. \m/
