Loosely Coupled Architecture: Easy Explanation

A loosely coupled architecture is a software application development model in which multiple components are connected but not heavily dependent on each other. Together, these components create a general network or system, despite each service being an independent entity created to perform a single task.

The primary purpose of a loosely coupled architecture is to create a system that doesn’t fail due to the failure of a single component. Service-oriented architectures (SOAs) typically comprise a loosely coupled architecture. Some of its benefits are scalability, maintainability, and extensibility.

• Example of a Loosely Coupled Architecture
• Loosely Coupled vs Tightly Coupled Architecture
• The Importance of Microservices in a Loosely Coupled Architecture
• Which AWS Services can be used for Loosely Coupled Architectures?
• Aspects to Consider when Choosing a Loosely Coupled Architecture
• AWS Serverless Scenario with Loosely Coupled Architecture
• Conclusion
• FAQs

Example of a Loosely Coupled Architecture

Consider an instance wherein you have created two classes in a program:

A and B. When a method of Class A calls the technique of Class B or uses variable instances defined in Class B, both classes are tightly coupled. However, when Class A depends on the interface of Class B instead of the methods defined in Class B, both classes are loosely coupled.

Another example is a food ordering app that uses a loosely coupled system; the app contains different services such as order, restaurant, delivery, and customer service. When a customer orders a food item, the order service processes it.

The restaurant service receives this data and prepares the food while the delivery service handles the delivery part. Customer service assists customers when needed. In this case, each service is not heavily dependent on the other services. All services communicate via APIs to send and receive the required information.

Therefore, when one service crashes, it can be instantly replaced without disturbing the other app components. Similarly, the order service can be automatically scaled during peak hours or seasons.

Loosely Coupled Architecture vs Tightly Coupled Architecture

Loosely coupled vs tightly coupled architecture is an important point to ponder.

• Loosely Coupled Architecture: The components or services in a system are independent, with minimal dependency on each other. They interact through APIs, allowing them to be independently managed, scaled, deployed, or replaced. Changes to one service don’t require changes in others. This architecture is flexible, scalable, and easy to maintain.
• Tightly Coupled Architecture: The components or services are highly dependent on each other. One component needs another to perform its tasks, and a change in one component often requires changes in others. This leads to more complexity and less flexibility as each component takes on multiple responsibilities.

The Importance of Microservices in a Loosely Coupled Architecture

Microservices is an architectural design that facilitates the development of an application as small and independent services that run their processes and communicate using lightweight protocols and messaging systems, making them platform-agnostic and language-agnostic.

Each service is independent, testable, highly maintainable, independently deployable, and implements a business capability. Most importantly, a small team maintains, deploys, creates, and owns each service. Microservices is a notable variant of a service-oriented architecture that leverages the loosely coupled architecture approach.

For example:

In an e-commerce portal, the order service should communicate with the customer or delivery service using APIs. That said, microservices best practices allow you to keep this coupling as minimal as possible.

Microservices comprise a set of collaborating services that work together using different coupling methods.

• Runtime Coupling: The degree to which the availability of one service impacts the availability of another service.
• Design-time Coupling: The degree to which a change in a service triggers change in another service.
• Infrastructure Coupling: The degree to which one service’s resource consumption impacts another service’s resource consumption.
  

Microservices benefits make it easy to implement loose coupling in a design-time coupling model while enabling you to efficiently handle coupling challenges using lean development and DevOps CI/CD best practices. 

Which AWS Services can be used for Loosely Coupled Architectures?

Amazon Simple Queuing Service (SQS) and Simple Notification Service (SNS) are powerful mechanisms that can help you build highly scalable and loosely coupled architectures, with coupling at the platform, network, and operation levels.

• Amazon Simple Queuing Service (SQS): When a client makes an order, the app that receives that order sends it as a message to the SQS. The message is queued and consumed by a function such as AWS Lambda. Once the message is processed, it’s automatically deleted.
  
• Amazon Simple Notification Service (SNS): Works as a “publish-subscribe” model wherein the application sends order messages to an SNS topic which is then replicated across various endpoints in order to run processes in parallel.
  
• AWS Lambda: Serverless compute engine.
  
• AWS Fargate: Container as a Service for serverless computing.
  
• AWS AutoScaling: Autoscaling service.
  
• Amazon S3: Storage service.
  
• Amazon API Gateway: API management service.
  
• AWS CloudWatch: Used to manage messages in SQS.

Aspects to Consider When Choosing a Loosely Coupled Architecture

It’s important to consider the following aspects when choosing a loosely coupled architecture.

• Compute: The underlying EC2 instance type should be determined based on the memory-to-compute ratio of an application.
  
• Network: Bandwidth and latency issues are not a concern in a loosely coupled scenario, as processes that run in parallel don’t need to interact much.
  
• Storage: Each loosely coupled app comes with a different storage requirement. Therefore, consider the dataset size and data transfer requirements.
  
• Deployment: Seeing as loosely coupled apps run on cores installed in different availability zones, they can be efficiently deployed using AWS ParallelCluster or AWS Batch.

AWS Serverless Scenario with Loosely Coupled Architecture

Serverless computing is a cloud-native software development approach that helps organizations easily and seamlessly build and run applications without the burdens of provisioning and managing servers.

Servers enable organizations to purchase back-end servers on a pay-as-you-go basis and only pay for the services used.

Serverless computing comes in two models:

• Function as a Service: A service that allows you to run code based on events without the complexities of infrastructure management. Applications run in a stateless mode wherein the server and client are loosely coupled and hence are independent, flexible, scalable and fault-tolerant.
  Regarding compute engines, AWS Lambda is a popular serverless FaaS tool from AWS. AWS Fargate is available for container-based workloads. For event triggering, we recommend using Amazon SQS, AWS SNS, and Eventbridge.
• Backend-as-a-Service: Running the server-side logic is outsourced to a cloud vendor. AWS BaaS tools include Amazon Elasticsearch Service for logging, AWS Kinesis for analytics and AWS Cognito for IAM.
  
  

What are the Three Types of Serverless Invocation Methods?

• Synchronous Invocation: Used when a client request requires an immediate response.
• Asynchronous Invocation: This is used when you don’t want the client to wait for a response and instead want to alert the client through a notification once the process is completed.
• Steaming Invocation: Used to upstream, process, and downstream data at the same pace.

Regarding serverless computing, a loosely coupled architecture with an asynchronous method is a good choice. That said, remember to ensure it is fail-fast and fans out properly.

This blog is also available on DZone

Regarding loosely coupled vs tightly coupled architecture, information flow and coordination between services are better in a tightly coupled architecture. However, they constrain you regarding flexibility when making changes to your apps on the go.

A loosely coupled architecture is the need of the hour. Not only does it allow you to swap or scale components instantly, but it also helps you add new features without affecting the availability and performance of the existing system. With microservices, lean development, and DevOps practices, a loosely coupled architecture allows you to stay in the competition or even ahead.

FAQs