Decoupling separates architectural components so they communicate through an intermediary rather than depending directly on one another. It reduces dependencies and helps one component continue operating when another is unavailable. section 14.3 section 16.0
Two practical forms are useful in AWS architectures:
- Synchronous decoupling keeps the interaction immediate while allowing the participants to remain unaware of each other. Elastic Load Balancing routes requests to healthy application instances and stops using failed ones. section 14.3 section 16.1.2
- Asynchronous decoupling uses a message queue so producers and consumers do not need to be available simultaneously. Amazon SQS requires application code to communicate through an SDK. section 14.3 section 16.1.2
Fault-tolerant web application
Place multiple EC2 instances in subnets across two Availability Zones behind an Elastic Load Balancer. If an instance fails, the load balancer stops routing requests to it and an Auto Scaling group replaces it. For background work, place messages in SQS and let EC2 workers process them asynchronously. section 16.1.2
Use the architecture diagram to trace synchronous decoupling between clients, an Elastic Load Balancer, redundant subnets, and EC2 instances; compare it with the SQS model when asynchronous processing is needed. section 16.1.2
Decoupling supports fault tolerance but does not remove every design concern. Redundancy must cover Availability Zones, subnets, and compute instances, while managed ELB and SQS provide fault-tolerant intermediaries. section 16.1.2
