Message oriented architecture is a great option to produce highly scalable, extendible and loosely coupled solutions. The message architecture describes the principal of using a software system that can send and receive (usually asynchronously) messages to one or more queues, so that services can interact without needing to know specific details about each other.
The problem is how can an application in an integrated architecture communicate with other applications that are interested in receiving messages without knowing the identities of the receivers?
The solution is to extend the communication infrastructure by creating topics or by dynamically inspecting message content. This allows applications to subscribe to specific messages.
This post will provide an illustration to turn a monolithic application into a distributed, highly scalable solution.
The Monolith
The conceptual model of a monolithic application is displayed below.
The application above consists of a collection of tightly coupled components. The side-effects are:
- Cumbersome release management - the entire application must be upgraded in order to release a new feature or fix a bug in any of the components.
- Low performance monitoring - isolating and measuring component throughput is difficult when all of the components are competing for the same resources.
- Poor scalability - dedicated resources cannot be allocated to individual components.
- High security risk - an attacker can gain access to all of the external dependencies once the application has been compromised.
Publish-Subscribe Solution
The conceptual model of a loosely coupled, Public-Subscribe (Pub-Sub) solution is displayed below.
The solution above consists of a queue based messaging system to decouple the components. The advantages are:
- Resource Isolation - each component can be hosted on a dedicated or shared environment.
- Decoupling - the online store's only responsibility is to write a message to a queue when an event occurs and therefore doesn't need to know who the subscribers are.
- Extendible - subscribers can be added or removed.
- Robust deployment - a single component can be upgraded without impacting others.
- Secure - an attacker needs to compromise all of the isolated components to gain access to the entire ecosystem.
- Testable - it is a lot easier to test component behaviour in isolation when the input and execution paths are limited.
Recovering from failure
The image below depicts the mail server being unavailable temporarily.
Recovering from temporary outages is easy since messages will continue to queue up.
Messages will not be lost during an outage. Dequeuing will occur once the service becomes available again.
Monitoring the queue length provides insight into the overall health of the system. The diagnosis of a high queue length is typically:
- An indication that the subscriber service is down.
- The subscriber is over-utilized and does not have the capacity to service the incoming messages fast enough.
Peak Load can be handled gracefully without stressing out resources since the email notification component will continually dequeue and process messages, one after the other, regardless of the number of messages in the queue. The email notification component will eventually catch up during periods of lower than normal use.
Load Distribution and Redundancy
The image below depicts distributing the mail server role across multiple workers.
Workload distribution can be achieved by deploying additional subscribers to dequeue and process messages from the same queue.
High availability, scalability and redundancy capabilities are provided when multiple subscribers are deployed to service the same queue. The system will remain online during maintenance by upgrading one subscriber at a time.
Performance benchmarking can be achieved by monitoring the queue length. Throughput can be predicated using the follow approach:
- Stopping the component server
- Filling the queue up with a large quantity of messages
- Starting the component server
- Measuring the number of messages that are processed per minute by monitoring the queue length
Lower latency can be achieved with geo-distributed deployments. For example, the Loyalty system, which is responsible for communicating with an external API, can be hosted in the same region as the API.
Summary
This post provided a laundry list of benefits for designing applications using a message based architectural pattern compared to traditional highly coupled monolithic applications. The Pub-Sub architecture is a proven and reliable approach to produce highly scalable solutions.