CLD120 Module 12 — Building Decoupled Architectures

Module Objective

Redesign tightly coupled components of an architecture into a loosely coupled one using AWS application integration services.

Modules 3–8All layers✓ built

Module 9Elasticity & HA✓ done

Module 10Automation✓ done

Module 11Caching✓ done

Module 12Decouplingyou are here

Module 13Serverless

Module 14Disaster recovery

Builds on Cloud Foundations Module 9 and this course’s Module 9: decoupling is what keeps elasticity and high availability working when a single component fails or slows down.

Tight vs. Loose Coupling Revisited

✗ Tightly coupled

Web tier

→

Fulfillment
waits for response

A slowdown or failure in the second component immediately becomes a slowdown or failure in the first.

✓ Loosely coupled

Web tier

→

Queue

→

Fulfillment

Each side works at its own pace; neither needs the other available at the same moment.

Note: a direct synchronous call is the simplest design — and loose coupling is the fix for the problem it creates.

Amazon SQS in Depth

SQS Feature	Architectural Benefit
Standard queue	At-least-once delivery, very high throughput, best-effort ordering
FIFO queue	Exactly-once processing and strict ordering, at lower throughput
Dead-letter queue	Captures messages that repeatedly fail processing, instead of losing or endlessly retrying them
Visibility timeout	Hides a message from other consumers while one consumer is processing it

Order spike
producer at peak rate

→

SQS queue
holds messages

→

Consumers
scale at their own pace

Queues absorb traffic spikes — a direct implementation of the elasticity from Module 9.

Amazon SNS in Depth

“Order placed” event

→

SNS topic
fan-out

→

SQS → Inventory
SQS → Billing
SQS → Customer notifications

SNS contributes

Fan-out: one event reaches many independent subscribers

SQS contributes

A durable queue for each consumer, so each processes at its own pace

SNS + SQS fan-out is a named pattern — one of the most common decoupling patterns in AWS reference architectures.

Amazon EventBridge in Depth

More sophisticated event routing: filter and route events by their content, across AWS services and external SaaS applications, through a shared event bus.

Order events

→

EventBridge rule
order total > threshold?

→

Only high-value orders
→ fraud-review service

EventBridge adds content-based routing. SNS delivers every message to every subscriber; EventBridge rules route events based on what they contain.

Choosing an Integration Pattern

Need	Likely Fit
One producer, one consumer, work queued for later processing	Amazon SQS
One event, many independent subscribers	Amazon SNS
Complex, content-based event routing across services	Amazon EventBridge

Decoupling adds points to monitor. Every queue, topic, or event bus needs monitoring — extend the CloudWatch monitoring from Module 9 to cover them.

Key Terms

Dead-letter queue: An SQS queue that captures messages which repeatedly fail processing
Visibility timeout: The period an SQS message is hidden from other consumers while one consumer processes it
Fan-out pattern: Publishing one event to multiple independent subscribers, commonly SNS delivering to multiple SQS queues
Content-based routing: Routing events according to their actual content, as supported by Amazon EventBridge rules

Review Questions

What problem does a synchronous, tightly coupled call between two components create that a queue solves?
What is the difference between a standard and a FIFO Amazon SQS queue?
How does the SNS-to-multiple-SQS-queues fan-out pattern combine the strengths of both services?
What capability does Amazon EventBridge add that Amazon SNS alone does not provide?