Skip to main content
Welcome students. In this lesson, we explore the differences between loose coupling and tight coupling—an essential concept in modern software architecture. This topic is frequently featured in the AWS Solutions Architect Associate Certification exam and related training programs. The main idea is to design a system such that if one component (or “colored ball”) fails or is removed, the entire system remains unaffected. In a tightly coupled system, the failure of one element can trigger a complete system collapse. In contrast, a loosely coupled system ensures that individual components can fail or be updated with minimal impact on the rest of the system.
The image illustrates the concept of coupling in software design, comparing loose coupling with interconnected circles and tight coupling with overlapping circles.

​
E-commerce Workflow Example

Consider a typical e-commerce workflow that includes navigation from the shopping cart to payment processing, invoice generation, inventory updates, labeling, dispatch, and finally tracking the dispatch. In a sequential, tightly coupled system, a failure in one service—such as the payment service—halts subsequent processes like invoice creation, inventory updates, and shipment tracking.
The image illustrates a tightly coupled system in an e-commerce application, showing a sequence of processes from cart to tracking. It highlights issues like sequential processing, degraded performance, and high cost.
To improve scalability and resilience, you can introduce a load balancer or a message queue (for example, AWS SQS) between the cart and payment services. This decoupling mechanism allows the cart service to enqueue messages that the payment service can process at its own pace. This isolation reduces the impact of failures and enables horizontal scaling.
The image is a diagram of a loosely coupled system for an e-commerce application, showing components like Cart, Payment, Invoice, Inventory, Labeling, Dispatch, and Tracking connected by message queues.
Loosely coupled systems typically offer increased scalability, enhanced resilience, easier maintenance, and simpler troubleshooting.
The image lists the advantages of a loosely coupled system, including scalability, resilience, maintainability, flexibility, and easy troubleshooting.

​
Scenarios for Implementing Loose Coupling

Loose coupling can be applied across multiple architectural scenarios:
  1. Microservices Architecture:
    In a microservices environment, if one user interface or service instance goes down, the remaining instances continue to serve the load without disruption.
  2. Message-Driven Architecture:
    In this design, messages are written to a queue by the sender and processed by the receiver at its own pace. Additional receivers can be added to handle increased loads, ensuring the sender is never blocked by processing delays.
  3. Event-Driven Architecture:
    Using a publish/subscribe model, the publisher broadcasts events while multiple subscribers process these events concurrently or in quick succession. This minimizes the need for direct, continuous interaction between services.
The image illustrates three types of loose coupling scenarios: Microservices Architecture, Message-Driven Architecture, and Event-Driven Architecture, each with a diagram showing their components and interactions.

​
Amazon SQS Overview

Amazon Simple Queue Service (SQS) is a powerful tool for decoupling components within distributed systems. Key benefits of SQS include:
  • Load leveling through asynchronous message processing.
  • Automatic scalability via the addition of consumers.
  • A proven producer/consumer model ensuring at least once processing.
SQS messages can be up to 256 KB. You can also utilize message attributes, dead letter queues for handling failed messages, and visibility timeouts that prevent duplicate processing.
The image illustrates the benefits of using Amazon SQS, highlighting message decoupling, load leveling, asynchronous processing, and scalable architecture.

​
Standard vs. FIFO Queues

Amazon SQS provides two types of queues to meet different needs:
  • Standard Queue:
    These queues offer high throughput and can handle hundreds of thousands of messages per second. However, message ordering is best-effort, meaning sequential delivery is not guaranteed, though at-least-once delivery is ensured.
The image illustrates the concept of SQS Standard Queues, showing unordered message delivery and listing advantages like best-effort ordering, at-least-once delivery, and maximum throughput. It also depicts various application/subscriber icons.
  • FIFO Queue:
    FIFO queues guarantee strict ordering with exactly-once processing. They have a throughput limit of approximately 300 messages per second (which can be increased to about 9,000 messages per second using batching). Although FIFO queues are slightly more expensive, they are essential when maintaining message order is critical.
The image illustrates an SQS FIFO Queue with numbered messages, showing its application/subscriber integration and listing advantages like strict ordering, 300 messages per second, and a 9,000 message limit.
Other SQS features include:
  • Batching of messages.
  • Configurable message retention (up to 14 days).
  • Message prioritization through attributes.
  • Handling failed processing using a dead letter queue.
The image illustrates the components of Amazon Simple Queue Service (SQS), showing the flow from producers to consumers, and highlighting features like message attributes, dead letter queue, visibility timeout, and message locking.

​
Use Cases for Amazon SQS

SQS can be utilized in various ways to enhance system reliability and scalability:
  • Decoupling microservices for enhanced reliability.
  • Cost-effective event-driven processing.
  • Maintaining strict message ordering and deduplication when necessary.
The image outlines four use cases for SQS: increasing reliability and scale, decoupling microservices and processing event-driven applications, being cost-effective and on-time, and maintaining message ordering with deduplication.

​
Introducing AWS EventBridge

For scenarios involving larger event sizes or more complex event decoupling, AWS EventBridge provides a comprehensive solution. EventBridge is a fully managed, serverless event bus that:
  • Supports high-volume event ingestion.
  • Routes and filters events using predefined rules.
  • Enables event replay for debugging and error recovery.
  • Provides a schema registry to manage and share data schemas.
The image illustrates the concept of decoupling with EventBridge, showing interconnected cubes representing events and highlighting benefits like decoupling, scalability, event processing at scale, and event routing and filtering.
Designed to integrate with numerous AWS services, EventBridge supports automatic scaling and event-triggered workflows with EC2, Lambda, S3, and Step Functions. It offers high availability (four nines) while ensuring that events are durably stored across multiple Availability Zones. Note that EventBridge is not designed to serve as a persistent data store.
The image is a graphic highlighting features of AWS EventBridge, including low code integrations, event replay, schema registry, and automatic retries.

​
Integrating SQS and EventBridge

Combining SQS with EventBridge enables the design of sophisticated, decoupled architectures. Consider the following integration:
  • A client application sends requests to a RESTful API Gateway.
  • A Lambda function processes the order acknowledgments and interacts with an order database.
  • The Lambda function publishes messages to SNS. Using event filters, SNS forwards copies of those messages to multiple SQS queues.
  • These SQS queues are polled by additional Lambda functions dedicated to notifications, inventory updates, and shipment processing.
This integration ensures that even if a Lambda function reaches its capacity or experiences delays, the SQS queues reliably hold the messages until processing resumes.
The image is a diagram illustrating the integration of AWS services, specifically combining SQS and EventBridge, to handle client application requests through an API Gateway, microservices, and message queues for notifications, inventory, and shipment processing.

​
Conclusion

Decoupling applications through load balancers, message queues, or event buses enables the design of systems that scale efficiently and adapt to variable loads with improved resilience. Loose coupling not only isolates failures but also simplifies maintenance and troubleshooting. Keep these principles in mind when designing systems to reliably handle dynamic workloads. Catch you in the next lesson.

Watch Video

Practice Lab