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 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 ordering within a message group and deduplicates sends inside a five-minute window. FIFO queues have lower default throughput limits, but high-throughput mode raises them a long way by spreading work across message groups, so "FIFO cannot scale" is rarely the deciding argument. The real question is whether the workload needs ordering or send-side deduplication at all, weighed against FIFO's higher price per request and the extra design work (group IDs, deduplication IDs). Default to standard; choose FIFO when the scenario says order matters or duplicate sends must be suppressed.

The message group ID decides what is ordered. FIFO ordering holds only inside one group. Messages in different groups are delivered in parallel to different consumers, while within a group, once a message (or a received batch of up to 10 from that group) is in flight, no further messages from that group are delivered until those are deleted or their visibility timeout expires. So the group ID should be the entity whose order matters: the account, the order, the device. One shared group ID for everything serialises the whole queue through one in-flight receive batch at a time; a random group ID per message gives you no ordering at all.

Deduplication works on sends, by deduplication ID. A producer either passes an explicit MessageDeduplicationId or turns on content-based deduplication, which uses a SHA-256 hash of the message body. Content-based deduplication fails when a retry changes the body (a timestamp, a request ID), because the hash changes; derive an explicit deduplication ID from a business key such as the order number instead. The group ID orders messages but never marks one as a duplicate. And deduplication does not stop redelivery: a message whose visibility timeout expires before it is deleted is delivered again, FIFO or not.

That is the visibility timeout. SQS does not delete a message when a consumer receives it; the message becomes invisible for the timeout while the consumer works, and the consumer deletes it after finishing. If the consumer crashes, the timeout expires and the message reappears for another consumer, which is how SQS retries. Set the timeout shorter than processing time and healthy consumers get interrupted by duplicates: "messages are processed twice" is fixed by raising the visibility timeout above the processing time, not by switching queue types. A consumer handling an unusually long message can extend that one message with ChangeMessageVisibility (up to 12 hours in total) instead of raising the timeout for the whole queue.

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 tier scales on the backlog to drain it. Dead-letter queues, retention and Lambda consumers are covered in the next section.

A queue only protects you for as long as it keeps messages. Message retention defaults to four days and can be set from 60 seconds to 14 days. If consumers are down longer than the retention period, the oldest messages are deleted unprocessed, so size retention to the longest outage you must survive. The visibility timeout does not extend retention; a message expires on its original schedule however many times it is received. (Kinesis Data Streams, by comparison, keeps records for 24 hours by default, extendable.)

A dead-letter queue (DLQ) catches poison messages. A redrive policy on the source queue moves any message received more than maxReceiveCount times into the DLQ, where you alarm on it and inspect it without blocking the main queue. Three details matter. The DLQ must be the same type as its source: a FIFO queue needs a FIFO DLQ, a standard queue a standard DLQ. For standard queues, a message keeps its original enqueue timestamp when it moves to the DLQ, so the DLQ's retention period should be longer than the source queue's, or messages that failed late can expire almost as soon as they arrive. And a redrive allow policy on the DLQ only controls which source queues may use it as their DLQ; it does not move anything.

After you fix the consumer, DLQ redrive moves the dead-lettered messages back to the source queue (or another queue) from the console or the StartMessageMoveTask API, with no custom copy code.

Lambda as the consumer. With an SQS event source mapping, Lambda polls the queue and invokes your function with batches. Four settings decide whether it behaves:

• Visibility timeout at least six times the function timeout (AWS's recommendation), so messages are not redelivered while a batch is still being processed or retried after throttling.
• Partial batch responses (ReportBatchItemFailures): the function returns the IDs of the messages that failed, and only those return to the queue. Without it, one bad message makes the whole batch visible again and the successful ones are processed twice.
• Maximum concurrency on the event source mapping (2 to 1,000) caps how many concurrent invocations that queue can drive, which is how you protect a downstream database. Reserved concurrency alone also caps the function, but by throttling it: throttled messages go back to the queue, count as receives, and can end up in the DLQ without ever failing.
• Provisioned concurrency keeps execution environments initialised so a predictable spike meets no cold starts; schedule it with Application Auto Scaling around known peaks. Reserved concurrency guarantees capacity but pre-warms nothing.

When several 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, HTTP/S endpoints, Amazon Data Firehose, and for notifications email, SMS and mobile push. The publisher knows nothing about the subscribers, so adding a consumer means adding a subscription, not changing producer code.

Keep the contrast with SQS sharp: an SQS message is consumed by one worker (competing consumers), while an SNS message is delivered to every subscriber. Three teams that each need every order event cannot share one SQS queue; they would take each other's messages.

SNS pushes and does not keep messages for later, which is why the standard pattern is SNS-to-SQS fan-out: subscribe one SQS queue per consumer. Each consumer gets its own durable buffer, retries, DLQ and scaling signal, and a consumer that goes offline for an hour simply accumulates a backlog while the others carry on.

Message filtering. A subscription filter policy delivers only matching messages to that subscriber. The filter policy scope can be the message attributes (the default) or the message body, so SNS can filter on fields inside a JSON payload without the publisher adding attributes.

Ordered fan-out with FIFO topics. When order must survive fan-out, use an SNS FIFO topic. SQS FIFO queues can subscribe only to SNS FIFO topics, and SNS FIFO topics deliver only to SQS queues (not directly to Lambda, HTTP endpoints or email); put Lambda behind the queue. The message group ID works as it does in SQS: set it to the entity whose order matters.

Encrypted queues. If a subscribed queue uses SSE-KMS, SNS must be able to use the key: the key policy has to allow sns.amazonaws.com kms:GenerateDataKey and kms:Decrypt. The AWS managed aws/sqs key's policy cannot be edited, so it cannot be used with SNS; use a customer managed key, or SSE-SQS (SQS-managed encryption, which is not a KMS key).

Amazon EventBridge is an event bus with rules: producers put structured JSON events on a bus, rules match them by content (source, detail-type or any field in the payload), and route matches to targets, for example sending only orders above a set value to a fraud-check workflow. One event can match many rules, so EventBridge fans out too. Since SNS can also filter on the message body, the choice between them rests on sources and targets rather than on filtering alone:

• Sources: the default bus already carries AWS service events (an EC2 state change, an API call recorded by CloudTrail), and SaaS partner event sources deliver supported third-party applications' events onto a partner event bus with no polling or webhook code.
• Targets: EventBridge rules can start Step Functions executions, run ECS tasks, call API destinations (third-party HTTP APIs with managed auth and rate limits) and send to other event buses, along with Lambda, SQS, SNS and Kinesis. SNS cannot deliver to Step Functions.

Cross-account events take three pieces. In the sending account, a rule targets the receiving account's event bus (rules created since March 2023 must also specify an IAM role that allows events:PutEvents on that bus). The receiving bus needs a resource-based policy allowing the senders to put events; a condition on aws:PrincipalOrgID grants a whole AWS Organization, including accounts created later. And events arriving on the receiving bus go nowhere until a rule on that bus routes them to local targets.

Amazon EventBridge Scheduler is the separate, serverless way to invoke a target on a schedule (one-time, rate or cron expressions, with time zones and retries), replacing a cron job on an EC2 instance that exists only to trigger work.

Archive and replay records events from a bus and re-sends a chosen time window later, which is how you reprocess events after fixing a consumer bug. For S3, turning on Amazon EventBridge delivery in a bucket's event notification settings sends every object event to the default bus, where rules can match on any field (key suffix, size, bucket) across many buckets and route to many targets. Native S3 notifications filter only by prefix and suffix per bucket, and overlapping filters for the same event type cannot go to different destinations.

The selection logic compresses to this. Choose SQS when one consumer group must reliably work through a backlog. Choose SNS when many subscribers need the same message with high throughput and minimal latency, typically fanning into SQS. Choose EventBridge when events come from AWS services or SaaS partners, when targets include Step Functions, ECS tasks or other accounts' buses, when routing rules belong in one central place, or when you need archive and replay.

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 handles long waits and human approval: a task can pause on a callback task token (.waitForTaskToken) until an external system or an approver responds, and a .sync integration waits for a job (an ECS task, a Glue job) to finish. Both patterns need the Standard workflow type. The two types differ like this:

Processing many items: Inline Map vs Distributed Map. An Inline Map state runs iterations inside the parent execution, up to 40 at a time, and every iteration's events count toward that execution's 25,000-event history limit, so it suits dozens or hundreds of items. A Distributed Map reads its items from S3 (a list of objects, a CSV or JSON file, an S3 Inventory report) and runs each item or batch as a child workflow execution, up to thousands in parallel, with MaxConcurrency to protect downstream services; it is built for millions of objects. If the job is simply one operation per object (copy, tag, restore, invoke a Lambda function) with no workflow logic, S3 Batch Operations is the simpler tool.

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 API contract; behind it you can swap a Lambda function for a container service, or route paths to different microservices, without any client changing. It also takes over cross-cutting work: throttling, authentication (IAM, Amazon Cognito, Lambda authorizers, JWT authorizers on HTTP APIs) and, on REST APIs, validation and caching.

API Gateway in front of Lambda is the standard serverless web or mobile backend: no servers to manage, capacity that scales per request and pay-per-call pricing on both sides. Its limits come from Lambda (a 15-minute maximum per invocation) and from API Gateway's own integration timeout, so long-running work belongs behind a queue or a Step Functions workflow rather than in the synchronous request.

API Gateway can integrate directly with AWS services, with no Lambda in between: a method can send to SQS or start a Step Functions execution. Both API types can do this (HTTP APIs have a first-class SQS-SendMessage integration), which makes "accept requests and queue them with least overhead" a no-code answer.

REST API vs HTTP API. HTTP APIs are cheaper and lower latency with fewer features. REST APIs add the controls the exam tests:

• Usage plans with API keys: per-client throttle limits and quotas (requests per day, week or month). These exist only on REST APIs.
• Stage caching: responses cached for a TTL (300 seconds by default, up to 3,600) so repeated reads never reach the backend.
• Request validators with models: malformed bodies or missing parameters are rejected with a 400 before the integration is invoked, so the backend never pays for bad requests.
• AWS WAF association.

Keep two controls apart. Throttling and quotas reject excess requests (HTTP 429); only caching serves repeated requests more cheaply. And an AWS WAF rate-based rule blocks requests from an IP address (or another aggregation key, such as a header) that exceeds a rate over a short window; it has no notion of a registered client with a monthly quota. Per-client throttles plus quotas means a REST API with usage plans and API keys.

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.

The decoupled work has to run somewhere, and the choice runs from most managed to most controlled. AWS Lambda is the default for short, event-driven, spiky work: it scales from zero automatically, bills per request and duration, and is a native target of SQS, SNS, EventBridge, S3 and API Gateway. Its defining constraint is the 15-minute maximum execution time: a task that can exceed it, or a long-lived process such as a persistent server, rules Lambda out. Steady very-high-volume workloads can also make per-invocation pricing worse than always-on containers.

AWS Fargate runs containers with no EC2 instances to manage: you declare CPU and memory per task, and AWS provisions and patches the capacity. It fits containerised, long-running work when the team wants no server management. Know its limits, because they decide many questions:

• No GPUs. GPU workloads need ECS or EKS on GPU EC2 instances.
• No privileged containers, and awsvpc network mode only (each task gets its own network interface). Host-level agents that need the host's network or kernel need the EC2 launch type.
• No DaemonSets on EKS Fargate, and no ECS daemon scheduling on Fargate. A monitoring or log agent that must run once per host uses the ECS daemon scheduling strategy (exactly one task per container instance) or a Kubernetes DaemonSet on EC2 nodes; on Fargate, the agent runs as a sidecar in each task or pod.

Fargate Spot runs interruptible tasks at a discount. Mix it with regular Fargate through a capacity provider strategy: base pins the first N tasks to one provider (say, FARGATE for a guaranteed minimum), and weight splits the remaining tasks between providers (say, 1 FARGATE to 3 FARGATE_SPOT).

ECS or EKS on EC2 trades convenience for control: specific instance types (GPUs, high memory), host daemons, privileged containers, or Reserved Instances, Savings Plans and Spot for steady capacity. ECS is the simpler AWS-native orchestrator; EKS is for teams that require Kubernetes itself (existing manifests, tooling or portability). Plain EC2 remains for full OS control or host-bound licensing.

Qualifiers do the rest: "least operational overhead" pushes toward Lambda or Fargate; "jobs take 40 minutes" eliminates Lambda; "must keep using existing Kubernetes manifests" forces EKS; "needs GPUs" eliminates Fargate.

Migrating an application into containers means packaging it as an image and removing everything that ties it to one machine, so any copy of the task can run anywhere and be replaced at any time. Lifting a monolith into ECS on Fargate as is buys consistent deployments and easier scaling without a rewrite; breaking it into microservices can come later. The work is in what the old server used to hold:

• Logs: write to stdout/stderr and use the awslogs log driver (or FireLens) to ship them to CloudWatch Logs. Fargate task storage is ephemeral, so log files written inside the container disappear with the task.
• Secrets and configuration: reference them in the task definition's secrets field (Secrets Manager secret or Parameter Store parameter ARNs); ECS injects them as environment variables at start-up. Never bake them into the image.
• Session state: move it to ElastiCache or DynamoDB so any task can serve any user.
• Shared files: use Amazon EFS. An EBS volume belongs to one Availability Zone and, in Kubernetes, is ReadWriteOnce: it attaches to one node at a time, and a pod using it is pinned to that zone. Replicas spread across several AZs that need the same files use EFS (the EFS CSI driver on EKS, ReadWriteMany; an EFS volume in the ECS task definition).

Lambda container images are a packaging option, not a different runtime model. An image (up to 10 GB) must implement the Lambda Runtime API, which you get by starting from an AWS base image or adding the runtime interface client, and the function still has the 15-minute limit and the event-driven invocation model. Packaging an existing web server as a Lambda image does not make it a long-running service; that workload belongs on Fargate or ECS.

The exam guide names AWS managed services by use case because the right answer is often "use the service built for this instead of running it yourself". Two pairs come up in Task 2.1.

Secrets Manager vs Parameter Store. Both store encrypted values that applications and ECS tasks fetch by reference. Secrets Manager adds built-in rotation: for Amazon RDS, Aurora, Redshift and DocumentDB it rotates credentials with AWS-provided rotation functions (or fully managed rotation for credentials RDS manages), updating the database and the secret together. Managed external secrets extend this to supported SaaS partners without a Lambda function; any other third-party secret needs a custom rotation function. Parameter Store SecureString parameters are KMS-encrypted and cheaper, but have no built-in rotation; an advanced-tier expiration policy can only notify you or delete the parameter. Rotating the KMS key does not change the password either: it changes the key material used to encrypt it.

AWS Transfer Family provides fully managed SFTP, FTPS, FTP and AS2 endpoints that store files directly in Amazon S3 or Amazon EFS. Partners keep their existing clients and workflows, and you stop patching, scaling and making highly available an SFTP server on EC2. When a scenario says partners "upload files over SFTP" and the data should land in S3 with least overhead, this is the service. Data-movement choices beyond it (DataSync, Storage Gateway) are covered in the data ingestion lesson.

Scale horizontally by default. Vertical scaling (a bigger instance) is simple but has a hard ceiling, usually needs a restart, and leaves a single point of failure. Horizontal scaling (more instances behind a load balancer) has no practical ceiling and adds availability, but needs stateless components. On SAA-C03, vertical scaling is usually the wrong answer dressed up as the easy one.

For EC2, horizontal scaling means an Auto Scaling group across several AZs, and the policy is a decision about what you know in advance:

AWS recommends pairing predictive scaling with target tracking: the forecast provisions for the regular cycle and target tracking catches the unplanned spike on top.

Scale queue consumers on backlog per instance. CPU is a poor signal for workers (they may wait on I/O while the queue grows), and schedules cannot follow bursts. AWS's recommended metric is backlog per instance: the queue's visible messages (ApproximateNumberOfMessagesVisible) divided by the number of running instances, published as a custom metric or built with metric math. Set the target to the backlog one instance can clear within your acceptable latency (acceptable seconds divided by average seconds per message) and let target tracking keep it there. More depth on fleet scaling is in the elastic compute lesson.

The load balancer is picked by protocol and by what clients need from its addresses.

• Non-HTTP protocols or long-lived TCP/UDP connections (game servers, MQTT, custom protocols) need an NLB.
• Clients that allowlist IP addresses need fixed addresses. An NLB gives one Elastic IP per AZ. Placing AWS Global Accelerator in front of an ALB also gives static IPs, but the ALB still only carries HTTP, HTTPS and gRPC, so it does not help a non-HTTP protocol.
• Long-lived HTTP/2 or gRPC connections stay uneven behind an NLB, because it balances whole connections and each client sticks to one target for its connection's life. An ALB balances each request, so gRPC calls spread across targets.
• Inline third-party appliances (firewalls, intrusion detection) are the Gateway Load Balancer.

Sticky sessions (session affinity via a load balancer cookie) keep each user on the same target. They are the fallback when session state cannot be moved out of the instance, for example when no code change is allowed. The cost: sessions on an instance that fails or is scaled in are lost, and load can skew toward instances holding long sessions. Where code can change, externalising state to ElastiCache or DynamoDB is the real fix. More on load balancers in the network architectures lesson.

A cache serves repeated reads from fast memory so the backend handles fewer of them, and the strategy decides how stale a cached value may be. Pick the layer first: CloudFront at the edge for HTTP content, API Gateway stage caching for repeated API responses, ElastiCache (Valkey, Redis OSS or Memcached) for application data and sessions, and DAX as an in-memory, API-compatible cache in front of DynamoDB.

Two misconceptions to avoid. An eviction policy such as allkeys-lru acts only when the cache reaches its memory limit; it does not free memory held by cold entries before then, and it does nothing for staleness. And a scheduled preload with a long TTL guesses the working set in advance, then serves whatever it loaded until the TTL ends, which breaks any short staleness requirement. The usual answer is lazy loading or write-through with a TTL sized to the staleness the business accepts. Cache engine choices are covered in the high-performance databases lesson.

CloudFront caches; Global Accelerator does not. That one difference answers most questions that offer both.

Amazon CloudFront is a CDN for HTTP, HTTPS and WebSocket traffic. It serves cached responses from edge locations, cutting both user latency and origin load, and carries uncached requests to the origin over the AWS network. How well it offloads the origin depends on the cache key. A cache policy decides which query strings, headers and cookies form the cache key; an origin request policy decides what is forwarded to the origin without becoming part of the key. Adding every query string or header to the cache key fragments the cache into near-unique entries and drops the hit ratio. Longer TTLs and Origin Shield (an extra regional caching layer that collapses origin fetches) do not fix a fragmented key; moving values out of the key into the origin request policy does. CloudFront can also reach an internal ALB or EC2 instance in a private subnet through VPC origins.

AWS Global Accelerator gives an application two static anycast IP addresses and carries TCP and UDP traffic from the nearest edge location over the AWS backbone to Regional endpoints (ALBs, NLBs, EC2 instances, Elastic IPs). Health checks steer traffic between Regional endpoint groups in seconds, without waiting for DNS caches to expire, which is where it beats Route 53 failover. It caches nothing, so every request still reaches your endpoints and origin load is unchanged.

Read replicas scale reads; Multi-AZ provides availability; RDS Proxy manages connections. Mixing them up is the trap.

RDS read replicas copy the primary asynchronously and serve read-only traffic (reports, read-heavy pages), so the primary handles the writes. Readers accept slight replication lag. A Multi-AZ DB instance deployment keeps a synchronous standby in another AZ that serves no traffic; it exists only for failover. A Multi-AZ DB cluster (MySQL and PostgreSQL) is different: its two standbys are readable, so it adds read capacity as well as failover.

Aurora endpoints. The cluster (writer) endpoint points at the primary; the reader endpoint load-balances across every Aurora Replica, including replicas you also placed in a custom endpoint. So pointing the application at the reader endpoint and the reporting tool at a custom endpoint does not isolate them: application reads still land on the reporting replicas. To separate workloads, create dedicated replicas and a custom endpoint for each workload, each listing only its own replicas.

RDS Proxy pools and shares database connections, which protects the database from connection storms (many Lambda invocations each opening a connection) and shortens failover for clients. It does not execute queries anywhere else: a primary saturated by query CPU still needs read replicas, caching or a bigger instance. Failover design is in the high availability lesson.

Storage type is chosen by how the application accesses data: object storage through an HTTP API, file storage through a shared file system, block storage as a disk attached to an instance.

EBS Multi-Attach lets one Provisioned IOPS (io1 or io2) volume attach to up to 16 Nitro-based instances in the same AZ, and the application must use a cluster-aware file system to avoid corrupting data. It is not a general way to share files; EFS is. Instance store gives the fastest local I/O but loses data when the instance stops. Volume types, FSx variants and S3 performance are in the high-performance storage lesson.

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.