Scalable, Loosely Coupled Architectures: SQS, SNS, EventBridge, Step Functions

Tight coupling means one component calls another synchronously and depends on that component being up, responsive, and correctly sized at that exact moment. A web tier that writes orders directly into a processing tier inherits every one of the processing tier's problems: if processing slows down, web requests time out; if processing crashes, orders are lost; if traffic spikes, both tiers must scale in lockstep or the whole chain fails. The failure of one component propagates to everything upstream of it. That propagation is what Task 2.1 asks you to design away.

Loose coupling inserts an intermediary — a queue, a topic, an event bus, a load balancer, an API — between components so that each side depends only on the intermediary, not on the other side's availability or capacity. Two benefits follow, and the exam tests both. First, resilience: if a consumer fails, work waits durably in the intermediary instead of being dropped, and the consumer catches up when it recovers. Second, independent scaling: each tier scales on its own signal — the web tier on request count, the worker tier on queue depth — so a spike in one place never forces an emergency resize of everything else.

Loose coupling is also why stateless design keeps appearing in this task. A component can only be scaled horizontally or replaced freely if any instance can handle any request, which means session state, uploaded files, and in-flight job data must live outside the instance — in ElastiCache or DynamoDB for sessions, S3 for objects, a queue for pending work. A multi-tier architecture (web, application, data) is the classic frame: each tier sits behind its own intermediary and scales independently, and microservices push the same idea further by giving each service its own deployment, data store, and scaling policy.

On the exam, this section is the diagnosis step. When a stem says requests are "lost during peak traffic," components "time out waiting for a downstream service," or two systems "must be updated together," you are being shown tight coupling — and the correct answer almost always introduces a managed intermediary rather than making the coupled components bigger.

Amazon SQS is the buffering intermediary, and SAA-C03 tests it at the decision level. The first decision is standard vs FIFO. A standard queue offers nearly unlimited throughput with at-least-once delivery and best-effort ordering — occasionally a message arrives twice or out of order, so consumers must be idempotent. A FIFO queue guarantees strict ordering within a message group and exactly-once processing (duplicates within the deduplication window are rejected), but the guarantee costs throughput: FIFO has a capped rate, while standard effectively does not. The decision rule: default to standard; choose FIFO only when the scenario explicitly says order matters ("transactions must be processed in the order received") or duplicates are unacceptable ("must be processed exactly once"). An answer that picks FIFO "to be safe" for a high-throughput workload with no ordering requirement is choosing a bottleneck.

The second concept is the visibility timeout. SQS does not delete a message when a consumer receives it — the message becomes invisible for the timeout period while the consumer works, and the consumer deletes it after finishing successfully. If the consumer crashes, the timeout expires and the message reappears for another consumer: that is the retry mechanism. Set the timeout shorter than the processing time and healthy consumers get interrupted by duplicates — the classic "messages are being processed twice" scenario is fixed by raising the visibility timeout, not by switching queue types.

Third, the dead-letter queue (DLQ). A malformed "poison" message that always fails would otherwise cycle through receive-fail-reappear forever, wasting consumer capacity. A redrive policy moves any message that has been received more than maxReceiveCount times into a DLQ, where you alarm on it and inspect it without blocking the main queue. Any scenario about "messages that repeatedly fail processing" is a DLQ question.

Finally, the pattern that makes SQS a resilience tool: the queue as a buffer. Put a queue between a web tier and a worker tier, and a traffic spike becomes a backlog instead of an outage — the web tier acknowledges instantly, the queue absorbs the burst durably, and the worker Auto Scaling group scales on queue depth to drain it. The exam presents this as the web-tier-to-worker-tier redesign constantly; recognize it from "requests are lost during traffic spikes" and answer with SQS plus workers scaling on the backlog.

SQS solves one producer feeding one logical consumer. When multiple independent systems must react to the same event, you need publish/subscribe, and on AWS that starts with Amazon SNS. A publisher sends one message to a topic; SNS pushes a copy to every subscriber — SQS queues, Lambda functions, HTTPS endpoints, Kinesis Data Firehose, and (for notification use cases) email and SMS. The publisher knows nothing about the subscribers, so adding a sixth consumer means adding a subscription, not changing producer code — that is loose coupling in the fan-out direction.

Know the crucial contrast with SQS delivery semantics: an SQS message is consumed by one worker (competing consumers), while an SNS message is delivered to every subscriber. A scenario where three teams each need their own copy of every order event cannot be solved with a single shared SQS queue — the teams would steal each other's messages. That elimination shows up repeatedly.

SNS is push-based and does not retain messages for later replay, which is why the exam's favorite pattern is SNS-to-SQS fan-out: subscribe an SQS queue per consumer to the topic. Each consumer now gets its own durable buffer, its own retry behavior via visibility timeout, its own DLQ, and its own scaling signal — the pub/sub reach of SNS combined with the resilience of queues. If one downstream system goes offline for an hour, its queue accumulates the backlog while every other subscriber continues unaffected. When ordering matters end to end, FIFO topics fan out to FIFO queues.

Two refinements are worth recognition-level knowledge. Message filtering: a subscription filter policy delivers only matching messages to a subscriber (for example, only order_cancelled events to the refunds queue), so consumers stop discarding traffic they never wanted. And SNS is regional, high-throughput, and low-latency — for straightforward one-to-many delivery it remains the simplest answer. On the exam, the trigger phrases are "multiple systems must be notified," "process the same message in parallel," and "add new consumers without modifying the application"; the answer is SNS, and if each consumer must process reliably at its own pace, it is SNS with SQS queues subscribed.

Amazon EventBridge is the third messaging service, and the exam expects you to pick correctly among SQS, SNS, and EventBridge rather than define each. EventBridge is an event bus with rules: producers put structured JSON events on a bus, rules match events by their content — source, detail-type, or any field in the payload — and route matches to targets such as Lambda, Step Functions, SQS, SNS, Kinesis, or API destinations. One event can match many rules, and one rule can drive multiple targets, so EventBridge does fan-out too, but its differentiator is content-based routing: "send orders over $10,000 to the fraud-check workflow, everything else to standard processing" is a rule expression, not consumer-side filtering code.

Three capabilities are strong exam signals for EventBridge. First, the default bus already carries AWS service events — an EC2 instance changing state, a change written to CloudTrail — so "trigger an action when an AWS resource changes state" is EventBridge. Second, SaaS partner event sources: supported third-party applications (the Zendesk/Datadog/Shopify category) deliver events directly onto a partner event bus with no polling code or webhook infrastructure — any scenario integrating a SaaS product's events points here. Third, operational extras like archive and replay (re-process past events after fixing a bug) and EventBridge Scheduler for cron-style invocation.

The selection logic compresses to this. Choose SQS when one consumer must reliably work through a backlog — buffering, load leveling, retries. Choose SNS when many subscribers need the same message with high throughput and minimal latency, typically fanning into SQS for durability. Choose EventBridge when the scenario needs routing decisions based on event content, ingestion of SaaS or AWS service events, cross-account event distribution, or an application decomposed around a shared event bus. Where the three overlap, the qualifier decides: "filter and route events by attributes in the payload" beats SNS's subscription filters in flexibility, while raw fan-out throughput with the simplest setup still favors SNS. Exam stems flag EventBridge with phrases like "route events to different targets based on content," "react to events from a third-party SaaS application," and "build an event-driven architecture across multiple accounts."

Queues and topics implement choreography — each service reacts to events with no central coordinator. Some processes instead need orchestration: an explicit, ordered, stateful workflow where step 3 runs only if step 2 succeeded, failures at any point are retried with backoff, and someone can see exactly where each execution stands. That is AWS Step Functions: you define a state machine of tasks (Lambda functions, ECS tasks, direct SDK integrations with over two hundred services), and Step Functions runs it with sequencing, Choice branching, Parallel branches, Map for fan-out over a collection, and per-step Retry and Catch policies with exponential backoff.

The exam's favorite framing is Step Functions versus chaining Lambda functions — one function synchronously invoking the next, or a tangle of functions wired through queues. Chaining fails in ways the exam wants you to articulate: a synchronous chain accumulates all the runtime into the first function's 15-minute limit and bills you for idle waiting; there is no central place to define retries or compensation when step 4 fails; and the workflow's current state lives nowhere, so a crash mid-chain leaves orphaned work. Step Functions externalizes the state, gives every step its own retry policy, and shows the execution visually. Trigger phrases: "multi-step process," "coordinate multiple Lambda functions," "retry individual steps," "if the step fails, the whole process must roll back or alert."

Step Functions also solves long waits and human approval. A Standard workflow execution can run for up to a year, and a task can pause on a callback task token until an external system or a human approver responds — "wait for manual approval before proceeding" is a Step Functions signal, not a Lambda one. Know the two workflow types at decision level: Standard for long-running, auditable workflows with exactly-once execution semantics; Express for high-volume, short-lived event processing where at-least-once semantics and lower cost per execution fit better.

Keep the boundary with SQS crisp, because the exam blurs it deliberately. SQS decouples two parties and buffers work; it has no notion of sequence across steps. Step Functions coordinates many steps with dependencies, branching, and error handling. If the scenario is "absorb bursts of independent jobs," queue it. If it is "run these five operations in order with retries and a failure path," orchestrate it.

Amazon API Gateway decouples clients from backends the way a queue decouples producers from consumers. Clients call a stable REST (or HTTP or WebSocket) API contract; behind it you can swap a Lambda function for a container service, or route different paths to different microservices, without any client changing. That indirection is the architectural point — plus a layer of managed cross-cutting concerns you no longer build yourself: throttling (rate and burst limits, plus per-client quotas via usage plans and API keys) that protects backends from being overwhelmed, request validation, authentication and authorization through IAM, Amazon Cognito authorizers, or Lambda authorizers, and an optional response cache that absorbs repeated reads before they touch the backend.

Two patterns earn their own recognition. First, API Gateway with Lambda is the serverless web backend — no servers anywhere, scaling from zero, pay per request. Second, API Gateway can integrate directly with AWS services: an API method can write straight into SQS or invoke Step Functions without a Lambda in between, removing glue code — a LEAST-operational-overhead favorite. Exam signals: "expose the service as a REST API," "throttle requests per client," "protect the backend from traffic spikes at the API layer," "different consumers need different rate limits."

With all five integration services covered, here is the selection table to memorize:

Most integration-service questions are answered by matching the stem to one row of this table and then checking the qualifier — the wrong options are usually other rows that solve a problem the scenario does not have.

Task 2.1 also tests where the decoupled work should run, and the decision compresses to a spectrum from most managed to most controlled. AWS Lambda is the default for short, event-driven, spiky work: it scales from zero to thousands of concurrent executions automatically, bills per request and duration, and integrates natively as the target of SQS, SNS, EventBridge, S3, and API Gateway. Its defining constraint is the 15-minute maximum execution time — any task that can exceed it, or any long-lived process like a persistent server or a streaming consumer that never exits, disqualifies Lambda outright. Steady very-high-volume workloads can also make per-invocation pricing worse than always-on containers, which the cost-qualifier questions exploit.

AWS Fargate runs containers without any EC2 instances to manage: you declare CPU and memory per task, and AWS provisions and patches the underlying capacity. It is the answer when the workload is containerized and long-running (or simply longer than 15 minutes), the team wants no server management, and there is no need to control the host. "Run containers without managing servers or clusters of EC2 instances" is the literal Fargate trigger phrase. ECS or EKS on EC2 trades that convenience for control: choose it when the scenario needs specific instance types (GPUs, high memory), daemon processes on every host, or aggressive cost optimization of steady capacity with Reserved Instances, Savings Plans, or Spot. Between the orchestrators, ECS is the simpler AWS-native choice; EKS is for teams that require Kubernetes itself — existing Kubernetes tooling, expertise, or portability across environments. Plain EC2 remains for workloads needing full OS control or licensing tied to hosts.

Migrating an application into containers is its own bullet in the guide. The judgment: containerizing a monolith "as is" (a lift into ECS/Fargate) buys deployment consistency and easier scaling without a rewrite, and is the right first step when the scenario wants to move off aging servers with minimal code change; refactoring into microservices comes later. Statefulness is the gate — a container should be stateless, so session data and files move to ElastiCache, DynamoDB, S3, or EFS as part of the migration.

Exam questions pair these with qualifiers: "LEAST operational overhead" pushes toward Lambda or Fargate; "jobs take 40 minutes" eliminates Lambda; "must continue using existing Kubernetes manifests" forces EKS.

Loose coupling makes independent scaling possible; this section is how each tier actually scales. Start with the direction. Vertical scaling — a bigger instance — is simple but has a hard ceiling, usually requires a restart, and leaves you with a single point of failure. Horizontal scaling — more instances behind a load balancer — has no practical ceiling and doubles as availability, but requires the stateless design covered earlier. On SAA-C03, vertical scaling is almost always the wrong answer dressed up as the easy one; it appears in options precisely so you can eliminate it.

For EC2, horizontal scaling means an Auto Scaling group spanning multiple AZs behind an Elastic Load Balancer. Know the scaling policies at decision level. Target tracking is the default and usually the right answer: you name a metric and a target (keep average CPU at 50%, or keep request count per target steady) and AWS computes the adjustments — least configuration, least overhead. Step scaling is for custom thresholds with different-sized responses; scheduled scaling is for known time-based cycles ("traffic doubles every weekday at 9 AM"); predictive scaling learns cyclical patterns and provisions ahead of them. And the pattern that ties this lesson together: a worker tier scales on queue backlog — a target tracking policy on backlog per instance drains an SQS spike automatically. On the load balancer side, the Application Load Balancer routes at layer 7 (paths, hostnames — the microservices front), while the Network Load Balancer handles layer 4 with static IPs and extreme TCP throughput.

Databases scale reads by decoupling them from the primary. ElastiCache (Redis or Memcached) absorbs repeated reads at sub-millisecond latency in front of the database and is also the standard externalized session store; DynamoDB has DAX for the same job. RDS read replicas offload read and reporting traffic over asynchronous replication — accepting slight staleness — so the primary handles only writes. Both are loose coupling for the data tier: readers stop contending with writers.

Finally, offload work before it reaches you at all. CloudFront caches static content at edge locations worldwide and accelerates dynamic requests over the AWS backbone, cutting both origin load and user latency. "Reduce load on the origin" and "improve performance for global users" both point at the edge. Exam stems combine these levers and ask for the one matching the bottleneck named in the scenario — cache reads if reads repeat, replicate if reports compete with writes, scale out if compute saturates.

Scenario 1 — the spike-buffering redesign. An e-commerce site runs a web tier that synchronously submits orders to a processing tier of EC2 instances. During flash sales, the processing tier saturates, web requests time out, and some orders are lost. The company needs a design that ensures no orders are lost and handles unpredictable spikes cost-effectively. Options: (A) move the processing tier to larger instances; (B) put an SQS queue between the tiers and run processors in an Auto Scaling group that scales on queue depth; (C) publish orders to an SNS topic that pushes to the processing instances; (D) increase the web tier's timeout values.

Eliminate A: vertical scaling raises the ceiling but keeps the synchronous coupling — a big enough sale still saturates it, orders are still lost at the limit, and you now pay for peak capacity all the time. Eliminate D: longer timeouts change when failures surface, not whether they happen; nothing stores the order. Eliminate C: SNS is push-based delivery to subscribers, not a durable work buffer with consumer-paced retrieval — it does not let the processing tier drain a backlog at its own pace. B is correct: the queue durably absorbs the spike (no lost orders), the web tier returns instantly, and workers scale out on backlog and back in afterward (cost-effective). This exact shape — synchronous tiers, spikes, lost work — is the most common Task 2.1 question.

Scenario 2 — the fan-out. When an order is placed, three systems must each process the event independently: inventory, shipping, and analytics. Each must process every event reliably even if it goes offline temporarily, and the company wants to add future consumers without modifying the ordering application. Options: (A) the application writes to one SQS queue that all three systems poll; (B) the application publishes to an SNS topic with an SQS queue subscribed per consumer; (C) the application calls each system's API in sequence; (D) a Step Functions workflow invokes each system.

Eliminate A: consumers on a single queue compete — each message is processed by one of them, so inventory would receive only a third of the events. Eliminate C: synchronous calls are tight coupling — one slow system delays the order path, and adding a consumer means changing application code. D actually works, but it is centralized orchestration for what is independent parallel consumption: adding a consumer means editing the state machine, and the ordering app becomes coupled to the workflow's completion. B is correct: SNS fans out a copy to every subscriber, each queue buffers durably through downtime, and new consumers are just new subscriptions. When two options both function, the one where consumers are independent and the publisher never changes wins the loose-coupling qualifier.