Coupling is a measure of how closely connected two functions, modules or applications are. Low coupling is often a good sign of a well architected system and good design practice since it allows you to lower cost of maintenance and high readability of code.
In this article I will highlight two approaches to achieve decoupling using Amazon Web Services (AWS): synchronous and asynchronous. With synchronous decoupling it requires both sides to be always available, however, they don’t need to ‘know’ each other. Meanwhile with asynchronous decoupling, communication is achieved even if the receiver is not available.
Synchronous In order to achieve synchronous decoupling an Elastic Load Balancing (ELB) could be used. An ELB distributes incoming application traffic across multiple EC2 instances, in multiple Availability Zones. You can add and remove instances from your load balancer as your needs change, without disrupting the overall flow of requests to your application.
There are two types of ELBs: 1. Application load balancers: work in between your web servers and the application servers, generally doing content-based routing. The nodes of an internal load balancer have only private IP addresses. Therefore, internal load balancers can only route requests from clients with access to the VPC for the load balancer. 2. Classic Load balancer: work in between the public Internet and your web servers.
Asynchronous For asynchronous decoupling, AWS offers a Simple Queue Service (SQS) that provides a messaging queue infrastructure. By using Amazon SQS, you can move data between distributed components of your applications that perform different tasks without losing messages or requiring each component to be always available.
There is a wealth of literature around messaging so I will not dive into the details. The important concept is that SQS allows you to decouple the production from the consumption of messages.
Each scenario will require that the Solution Architect picks the most suitable strategy to decouple applications.