Module 8 · SAA-C03

Application integration and decoupling

SQS, SNS, EventBridge, Step Functions, API Gateway: decouple to absorb load, tolerate failures and scale independently.

DomainResilient architectures
DomainHigh-performing architectures
13 diagrams
10 scenarios
11 services

5-minute essentials

Decoupling = putting a queue or event bus between two components so one being slow or failing does not drag down the other.Questions mentioning "traffic spikes", "must not lose requests", "slow processing component" usually need SQS in the middle.
SQS is a pull queue: consumers poll for messages; each message is processed by only one consumer and then deleted.It is not a broadcast. To send one message to many places: SNS fan-out or EventBridge.
SQS Standard: nearly unlimited throughput, at-least-once delivery, ordering not guaranteed. FIFO: strict order within each message group, no duplicates (5-minute dedup).Standard consumers must be idempotent because a message can arrive twice.
Visibility timeout: a message being processed is hidden (default 30 seconds, max 12 hours); after processing you must call DeleteMessage, otherwise the message reappears.Processing longer than the visibility timeout → duplicate processing. Increase the timeout or call ChangeMessageVisibility.
Dead-letter queue (DLQ): a message received more than maxReceiveCount times that still fails is moved to the DLQ for separate inspection.Stops a bad (poison) message from being reprocessed forever; redrive moves messages from the DLQ back to the source queue.
Long polling (WaitTimeSeconds up to 20 seconds) reduces empty receives and lowers cost.Question asks to "reduce API calls / SQS cost when the queue is often empty": enable long polling.
SNS is push pub/sub: a message published to a topic is delivered to every subscriber (SQS, Lambda, HTTP, email, SMS…).SNS + multiple SQS = fan-out: each system has its own queue, processes independently, and loses nothing when a consumer is temporarily down.
EventBridge: an event bus with content-based filtering rules, receiving events from AWS services, SaaS apps and your own apps.Reacting to AWS resource state changes (EC2 stopped, GuardDuty finding…) or receiving SaaS events: EventBridge, not SNS.
Step Functions orchestrates multiple steps with retry, catch, wait and parallel branches. Standard runs up to 1 year, exactly-once; Express up to 5 minutes, for high volume.Multi-step workflow where you need to know the current step and handle errors per step: Step Functions instead of Lambda calling Lambda.
API Gateway: an HTTP/REST/WebSocket front door for Lambda or a backend, with throttling, caching (REST), authorization and usage plans.Default 10,000 requests/second per account per Region; integration timeout up to 29 seconds by default.
Amazon MQ is managed ActiveMQ / RabbitMQ, speaking standard protocols (JMS, AMQP, MQTT, STOMP, OpenWire).Moving an app that uses a standard message broker to AWS without code changes: Amazon MQ. Building new on AWS: SQS / SNS.
Kinesis Data Streams: a data stream ordered per shard; multiple consumers can re-read it within the retention period.Many apps reading the same stream, needing replay or ordered real-time processing: Kinesis. One job, one consumer per message: SQS.
SQS messages are up to 1 MiB; for larger ones store the payload in S3 and send a reference (extended client library).Older questions say 256 KB; the current SQS limit is 1 MiB.

Diagrams

Decoupling with SQS: the queue absorbs load spikes

Web just writes the order to the queue and responds immediately. Workers in an Auto Scaling group pull messages at their own pace and scale on queue backlog.

Step by step

Web writes the order to SQS and responds to the user immediately, without waiting for processing.
Workers pull a message, process it, write the result, then delete the message from the queue.
Backlog grows: the alarm triggers a scaling policy to add workers; with few messages, workers are removed.

Lifecycle of an SQS message: visibility timeout and dead-letter queue

A message being processed is hidden for the visibility timeout. If it isn't deleted in time it reappears; after more than maxReceiveCount receives it moves to the DLQ.

SNS fan-out to multiple SQS queues

One message published to the topic is pushed into each queue. Each system reads its own queue at its own pace; a filter policy lets each queue receive only the message types it needs.

Step by step

The order service publishes once to the SNS topic.
SNS pushes a copy of the message into each queue; the email queue receives only messages matching its filter policy.
Each system processes independently; if one is temporarily down, its messages stay in its queue.

EventBridge: events from AWS, SaaS and apps to targets

Events enter the event bus; each rule filters on content (source, type, any field) and sends to up to 5 targets. Archive stores events for replay.

Step by step

AWS services, SaaS partners and your apps send events to the bus.
A rule matches the EC2 stopped event and sends it to Lambda and SNS.
A rule matches order.created and starts a Step Functions workflow.
Archive keeps events for replay when they need reprocessing.

Step Functions orchestrating an order workflow

Each step is a state with Retry / Catch. The approval step waits with a task token; if payment fails, the flow takes the compensation branch.

Step by step

API Gateway starts the workflow; steps run in sequence, and transient errors are retried.
Payment done: send an approval request and wait (possibly days) until the task token comes back, then write the result.
Payment fails for good: Catch moves to the compensation step.

API Gateway in front of Lambda, with per-client throttling and SQS buffering

A usage plan limits each client. Synchronous requests go to Lambda; high-volume write requests can integrate directly with SQS for buffering.

Step by step

Each client's API key is attached to its own usage plan (rate, burst, quota); exceeding it returns 429.
Reading orders: Lambda handles it synchronously (integration timeout up to 29 seconds by default).
Writing high-volume events: API Gateway pushes directly into SQS, and workers process them later.

SQS FIFO: ordering per message group, parallel across groups

Messages with the same MessageGroupId are delivered in order, one at a time. Different groups are processed in parallel.

Step by step

The producer sends a MessageGroupId (account ID) and a deduplication ID; duplicates within 5 minutes are dropped.
Each group delivers messages one by one in order; the two groups run in parallel on two consumers.

Kinesis Data Streams: many consumers reading one stream

Records are split into shards by partition key and kept for the retention period. Each consumer reads every shard from its own position and can re-read. With SQS, each message goes to only one consumer.

Step by step

Records with the same partition key go to the same shard, keeping order within the shard.
Three apps read the whole stream, each tracking its own read position; Firehose writes to S3.

Amazon MQ: moving a JMS app to AWS without code changes

The app keeps its JMS client (OpenWire / AMQP) and only changes the broker address. Active/standby brokers in two AZs share storage for fault tolerance.

Step by step

The app moves to EC2 and still speaks JMS / OpenWire to the broker.
Active/standby in two AZs share storage; if the active broker fails, the standby takes over.

SQS short polling vs long polling

Short polling (default) queries only a subset of servers and returns immediately, even when empty. Long polling (WaitTimeSeconds > 0, max 20 seconds) queries all servers and waits until a message arrives: fewer empty calls, so it is cheaper.

Step Functions: choosing a state type for each step

Task does work (calls Lambda or an AWS service); the other states control flow: Choice branches, Parallel runs several branches at once, Map iterates over array items, Wait pauses, Pass passes data along, Succeed / Fail end the run.

Step by step

Processing each order in a batch: no branching, no different parallel branches.
Repeat the same steps for each order: Map.
Inside each iteration, call Lambda to decrement stock: Task.

AppSync: one GraphQL endpoint over many data sources

Clients send queries / mutations to one GraphQL endpoint; resolvers fetch data from DynamoDB, Lambda or an existing HTTP API. Subscriptions push changes to clients over WebSocket. Auth via API key, IAM, Cognito, OIDC or Lambda.

Step by step

The app signs in with Cognito and sends a query with the token; AppSync verifies the token.
One query can combine data from several sources through resolvers.
A mutation changes data: subscribed clients get the update immediately over WebSocket.

Choosing an integration service

Ask in order: does it go to many parties, is it a data stream that needs replay, does the app use a standard message-broker protocol, is it a multi-step workflow. If none apply: SQS for buffering and decoupling.

Step by step

A new order must reach inventory, billing and email: SNS fan-out (usually with one SQS queue per system).
One tier hands work to a processing tier and needs to buffer load spikes: SQS.

Quick comparisons

SQS, SNS, EventBridge, Kinesis Data Streams

	SQS	SNS	EventBridge	Kinesis Data Streams
Model	Queue, consumers pull	Pub/sub, pushed to subscribers	Event bus, content-based rules	Sharded stream, consumers read by position
One message goes to	One consumer	Every subscriber	Every target of matching rules	Every consumer (each reads on its own)
Retention	Default 4 days, max 14 days	None (delivered immediately, with retries)	None; archive for replay	Per the stream's retention period
Ordering	FIFO: within message group	FIFO topic: within message group	Not guaranteed	Within each shard
Best for	Load buffering, decoupling workers	Fan-out, notifications	Reacting to AWS / SaaS events, routing	Logs, clickstream, IoT, real-time analytics

SQS Standard vs FIFO

	Standard	FIFO
Ordering	Best effort, not guaranteed	Strict order within each message group
Delivery	At least once (duplicates possible)	Exactly once (dedup within 5 minutes)
Throughput	Nearly unlimited	300 TPS per API (3,000 messages/second with batches of 10); high throughput mode is much higher
Queue name	Any	Must end in .fifo
Use when	Default for most workloads	Bank transactions, orders, commands that must stay in order

Step Functions Standard vs Express

	Standard	Express
Max duration	1 year	5 minutes
Semantics	Exactly once	Async: at least once; Sync: at most once
Pricing	Per state transition	Per execution, duration, memory
Best for	Long-running workflows, human approval, payments	IoT, stream processing, high-volume backends

Amazon MQ vs SQS / SNS

	Amazon MQ	SQS / SNS
Protocols	JMS, AMQP, MQTT, STOMP, OpenWire	AWS API (HTTPS)
Operations	Broker runs on instances (you pick the size), Multi-AZ active/standby	Serverless, scales automatically
Use when	Migrating apps on ActiveMQ / RabbitMQ without code changes	New applications on AWS

Exam scenarios

1A web app takes orders; during promotions order volume jumps 20x, the processing tier can't keep up and drops orders. Orders must not be lost, at reasonable cost.

Show answer

Right: Put SQS between web and the processing tier; workers in an Auto Scaling group scale on queue backlog (ApproximateNumberOfMessagesVisible / messages per instance)
The queue absorbs the spike, workers drain it gradually, no orders are lost.

Wrong: Scale the processing tier's EC2 instances up to a very large size
Expensive at normal times and still has a ceiling; doesn't fix the tight coupling between web and processing.

Wrong: An SNS topic between web and the processing tier
SNS doesn't retain messages; even when consumers are overloaded, messages must be delivered immediately.

2A malformed message crashes the consumer; the message returns to the queue and is reprocessed hundreds of times.

Show answer

Right: Configure a dead-letter queue with maxReceiveCount (e.g., 5)
After 5 receives without being deleted, the message moves to the DLQ for investigation and stops blocking other messages.

Wrong: Lower the visibility timeout
The message just comes back faster and keeps failing forever.

3The consumer takes about 2 minutes per message; many messages are processed twice.

Show answer

Right: Increase the visibility timeout beyond the processing time (or call ChangeMessageVisibility while processing)
The default visibility timeout is 30 seconds: the message reappears to another consumer before processing finishes.

Wrong: Switch to a FIFO queue
FIFO prevents duplicates on the send side (dedup); it doesn't stop a message reappearing when processing exceeds the visibility timeout.

4When a new order arrives, three systems (inventory, billing, email) must each receive and process it independently; no message may be lost if any system is temporarily down.

Show answer

Right: SNS topic fanning out to three SQS queues, each system reading its own queue
Each queue keeps messages up to 14 days; filter policies can let each queue receive only the message types it needs.

Wrong: One SQS queue read by all three systems
Each message goes to only one consumer; the three systems would split the messages between them.

Wrong: SNS sending HTTP directly to the three systems
If a system is down for long, retries run out and messages are lost.

5You need to run a Lambda function whenever an EC2 instance in the account changes to the stopped state.

Show answer

Right: An EventBridge rule matching the "EC2 Instance State-change Notification" event with state = stopped, targeting Lambda
AWS services send events to the default event bus automatically; the rule filters on content.

Wrong: A Lambda running every minute that calls DescribeInstances
Polling is costly and slow.

Wrong: CloudTrail sending directly to Lambda
CloudTrail logs API calls; it is not an event routing mechanism.

6An order workflow includes inventory check, payment, shipping, and a human approval step that can wait several days; each failed step must be retried or compensated.

Show answer

Right: Step Functions Standard (Retry, Catch, .waitForTaskToken callback for the approval step)
Runs up to 1 year, exactly-once, with every step visible in the execution history.

Wrong: One Lambda calling the other Lambdas in sequence
Lambda maxes out at 15 minutes, can't wait for days, and hand-written retry / compensation is very complex.

Wrong: Step Functions Express
Max 5 minutes.

7Stock trades for each account must be processed in order without duplicates; different accounts can be processed in parallel.

Show answer

Right: SQS FIFO, MessageGroupId = account ID
Order is kept within each group; different groups are processed in parallel.

Wrong: SQS Standard
No ordering guarantee; duplicates possible.

Wrong: FIFO queue with one shared MessageGroupId for everything
Correct order, but strictly sequential processing with no parallelism.

8A company is moving a Java app that uses JMS with on-premises ActiveMQ to AWS, with minimal code changes.

Show answer

Right: Amazon MQ for ActiveMQ
Managed broker that keeps the JMS / OpenWire protocols; enable Multi-AZ active/standby for HA.

Wrong: Rewrite the messaging layer with SQS
Requires code changes and a different API.

9Clickstream data must be read by three apps (real-time metrics, S3 storage, fraud detection) at the same time, with replay on failure.

Show answer

Right: Kinesis Data Streams with multiple consumers (Lambda, Firehose → S3, a custom app)
Data stays in the stream for the retention period; each consumer reads from its own position.

Wrong: SQS Standard
Each message goes to one consumer and is gone once deleted; no replay.

10A public API on API Gateway + Lambda is hammered by one client, affecting other clients.

Show answer

Right: Usage plan + API key with per-client throttling and quota (REST API)
Limits each client at the API front door; clients over the limit get 429.

Wrong: Increase the Lambda reserved concurrency
Only lets the bad client use even more.

Quick picks

How should the components be connected?

When you need	Use
Buffer load spikes between two tiers, each job handled by one worker	SQS Standard + Auto Scaling on queue depth · see diagram
Process in order, no duplicates	SQS FIFO (MessageGroupId) · see diagram
Failing messages loop forever	Dead-letter queue + maxReceiveCount · see diagram
One message to many systems, not lost if a system is temporarily down	SNS fan-out → multiple SQS · see diagram
React to AWS service or SaaS events, filter on content	EventBridge (rule + target) · see diagram
Run on a schedule (cron)	EventBridge Scheduler
Multi-step workflow, retries, waiting for approval	Step Functions Standard · see diagram
High volume, short executions (under 5 minutes)	Step Functions Express
HTTP front door for Lambda / backend, per-client throttling	API Gateway (usage plan) · see diagram
Many consumers reading the same stream, with replay	Kinesis Data Streams · see diagram
App already uses JMS / AMQP / MQTT	Amazon MQ · see diagram
GraphQL, real-time data sync for mobile apps	AWS AppSync · see diagram

Common pitfalls

Using one SQS queue for several systems that all need every message: SQS splits messages, it does not broadcast.
Processing longer than the visibility timeout, so messages get processed twice.
Forgetting to delete a message after processing: it returns to the queue.
Failing messages loop forever because no dead-letter queue is configured.
Choosing FIFO for a workload that needs massive throughput but not ordering.
Using a single MessageGroupId for all FIFO messages and then wondering why nothing runs in parallel.
Using SNS (no retention) when the question requires load buffering or no message loss while a consumer is down.
Using CloudTrail or polling to "catch events" instead of an EventBridge rule.
Chaining Lambda calls for a long workflow instead of Step Functions.
Choosing Step Functions Express for a workflow that runs longer than 5 minutes.
Rewriting a JMS app for SQS when the question asks for minimal code changes (that's Amazon MQ).
Remembering the SQS message limit as 256 KB: it is now 1 MiB.

Services in this module

Numbers that change (checked against AWS docs)

SQS: messages up to 1 MiB; retention default 4 days (1 minute to 14 days); visibility timeout default 30 seconds, max 12 hours; delay up to 15 minutes. checked 2026-10-16 ↗
SQS FIFO: 300 transactions/second per API (3,000 messages/second with batches of 10); long polling up to 20 seconds; up to 120,000 in-flight messages. checked 2026-10-16 ↗
SNS: topics accept messages up to 256 KiB by default, configurable up to 1 MiB (only with SQS, Lambda, Firehose subscribers). checked 2026-10-16 ↗
Step Functions: Standard up to 1 year, exactly-once, billed per state transition; Express up to 5 minutes, billed per execution, duration and memory. checked 2026-10-16 ↗
EventBridge (classic): up to 5 targets per rule. checked 2026-10-16 ↗
API Gateway: default 10,000 requests/second per account per Region (burst 5,000). checked 2026-10-16 ↗
API Gateway REST: integration timeout 50 ms – 29 seconds, can be raised for Regional / private APIs; payload up to 10 MB. checked 2026-10-16 ↗
Lambda + SQS: Lambda polls messages in batches, at-least-once processing; use partial batch response to avoid reprocessing messages that already succeeded. checked 2026-10-16 ↗
SQS: short polling queries only a subset of servers and returns immediately even when empty; long polling (WaitTimeSeconds > 0) queries all servers and waits up to 20 seconds. checked 2026-10-19 ↗
Step Functions has Task plus 7 flow states: Choice, Parallel, Map, Pass, Wait, Succeed, Fail. checked 2026-10-19 ↗
AppSync: serverless GraphQL subscriptions over WebSocket; auth via API key, IAM, Cognito, OpenID Connect or Lambda. checked 2026-10-19 ↗

Practice this module →