There’s a growing trend among developers to shift applications from the traditional monolithic architecture to the more agile and flexible microservices architecture. One common approach to making the transition is the Strangler pattern, where microservices replace small pieces of functionality until the legacy system is finally decommissioned. This pattern minimizes migration risks and simplifies the process, but it can get complex to run both architectures concurrently.
AWS has two messaging tools that make using the Strangler Pattern more manageable – Simple Notification Service (SNS) and Simple Queue Service (SQS). This article outlines what these tools are and how they help keep distributed databases in sync.
SNS and SQS Defined
SNS is a system that allows delivery of a published message to any subscribed endpoints. It serves as a repository for Topics. SQS is a messaging queue service that can store messages while waiting for a system to process them. Publishers and Subscribers are created once the Topic is established. An SQS queue can be subscribed to an SNS Topic.
How They Work
When used in conjunction, SNS and SQS can help decouple and scale microservices. Using the Strangler pattern, you’ll gradually be replacing pieces of your monolith with microservices. Throughout this journey, you’ll need the two to communicate. Below, we configure these AWS messaging tools to make this communication more flexible and reliable. The microservice acts as the Publisher and the SQS queue serves as the Subscriber, eventually pushing messages to the monolith.
When the Publisher sends a message to a specific Topic, SNS will send the message to any subscribed SQS queues. For example, the microservice created an instance of a customer object:
In this case, we are still using portions of the monolith that require the new customer information, so we must relay the data from the microservice to the heritage database. Consequently, the Publisher sent a message contract to SNS containing the customer information and the SNS Topic found below.
SQS is on stand-by, looking for any messages sent to the SNS topic AWS123. When the Subscriber sees that we published a new message, it grabs it and loads it into the queue. The client’s monolith application can then ingest this message and use the information to create a replica instance of Customer, ensuring the same data is found in both applications.
Benefits of AWS Messaging Tools
As shown above, the Strangler pattern allows microservices to use resources from the monolith as they are deployed. Utilizing SNS and SQS messaging tools allows the distributed databases to exchange messages without requiring each to be concurrently available. These tools eliminate the need to frequently check for updates. This structure is optimal for scalability because the separate services aren’t bound together by complicated interdependencies.
Utilizing these AWS messaging tools together allows the microservice and the monolith to communicate efficiently, update concurrently, and share and process real-time data. 
the experts at DragonSpears for more advice on tools and strategies to make the migration from monolith to microservices as smooth as possible.
