Skip to content
FR

Design Scalable and Loosely Coupled Architectures

Step 7 of 28

AWS Loosely Coupled Architectures: SQS, Events, and Serverless

Where this lesson fits

This lesson covers Domain 2: Design Resilient Architectures, Task 2.1: Design scalable and loosely coupled architectures. Domain 2 carries 26% of the scored content of the SAA-C03 exam. For AWS SAA-C03, a loosely coupled architecture separates demand from processing capacity. Choose APIs, messaging, workflows and compute so components absorb spikes and fail independently.

Learning objectives

After this lesson you will be able to:

  • Explain why loose coupling and statelessness make systems scalable and resilient.
  • Choose between Amazon SQS, Amazon SNS, Amazon EventBridge, Amazon Kinesis and Amazon MQ.
  • Configure Amazon SQS correctly: visibility timeout, long polling, dead-letter queues, standard versus FIFO.
  • Select the right API option with Amazon API Gateway and know its throttling, caching and authorization features.
  • Orchestrate multi-step workflows with AWS Step Functions.
  • Choose between AWS Lambda, AWS Fargate, Amazon ECS on EC2 and Amazon EKS for a given workload.

Architecture map

An order event is published once and delivered to separate queues. Consumers retry independently; design for duplicates and route repeated failures to DLQs.

1. Tight coupling versus loose coupling

A tightly coupled checkout calls payment and email synchronously. A slow dependency makes callers wait; its failure can fail the order. Shared scaling and deployment constraints compound the problem.

In a loosely coupled design, components communicate through an intermediary (a queue, a topic, an event bus or an API), so each one can scale, fail and be deployed independently.

Principle What it means AWS building blocks
Decouple with queues The producer drops a message and moves on; consumers process at their own pace Amazon SQS
Fan out with topics One message is delivered to many subscribers Amazon SNS, EventBridge
React to events Components publish facts ("order placed") and others subscribe EventBridge, SNS, S3 event notifications
Stay stateless No session or file state on the compute node, so any node can serve any request ElastiCache, DynamoDB, Amazon EFS, S3 for state
Scale horizontally Add identical nodes, do not enlarge a single node Auto Scaling, Lambda, Fargate
Use managed services Offload undifferentiated heavy lifting SQS, API Gateway, Lambda, DynamoDB

A useful exam shortcut: when a question mentions spiky traffic, a slow downstream system, or the need to avoid losing requests, consider an SQS queue between the tiers, then check whether latency, ordering, retention and failure handling meet the requirement.

2. Messaging and event services

2.1 Amazon SQS

Amazon SQS is a fully managed message queue.

Feature Standard queue FIFO queue
Throughput Nearly unlimited 300 messages per second per API action (3,000 with batching); high throughput mode scales much higher
Ordering Best effort Strict order within a message group
Delivery At least once (duplicates possible, so consumers must be idempotent) Send deduplication within a 5-minute window; consumers can still retry and must make business side effects idempotent
Queue name Any Must end with .fifo

Settings you must know:

  • Visibility timeout (default 30 seconds, up to 12 hours): after a consumer receives a message, it is hidden from other consumers for this time. If the consumer does not delete the message before the timeout, it becomes visible again and may be processed again. Set it to at least the maximum processing time (for a Lambda consumer, AWS recommends at least six times the function timeout plus any batching window).
  • Message retention: 4 days by default, up to 14 days.
  • Long polling (ReceiveMessageWaitTimeSeconds up to 20): reduces empty responses and cost compared with short polling.
  • Dead-letter queue (DLQ): after a message has been received repeatedly without successful deletion beyond the configured maxReceiveCount, it moves to a DLQ for inspection. A DLQ for a FIFO queue must also be FIFO.
  • Delay queues postpone delivery up to 15 minutes. Message size is limited to 1 MiB. For larger payloads store the data in S3 and send a pointer (the Extended Client Library pattern).
  • Encryption: SSE-SQS by default, or SSE-KMS (see the previous lesson).
  • Fair queues (introduced in 2025) reduce the "noisy neighbor" effect in multi-tenant standard queues by keeping dwell time consistent across tenants.

Scaling pattern: an Auto Scaling group scales on the custom metric "queue depth per instance" (ApproximateNumberOfMessagesVisible divided by the number of instances). This is the textbook answer for "process jobs in the background and scale with the backlog".

2.2 Amazon SNS

SNS is a pub/sub service: publishers send to a topic; subscribers (SQS queues, Lambda functions, HTTP/S endpoints, email, SMS, mobile push, Amazon Data Firehose) each receive a copy. The SNS + SQS fan-out pattern sends one event to several queues so that different consumers (billing, shipping, analytics) work independently and each has its own retry and DLQ behavior. Message filtering on subscriptions lets each subscriber receive only relevant messages. SNS FIFO topics preserve order for FIFO queues.

2.3 Amazon EventBridge

EventBridge is a serverless event bus with rules that match event patterns and route them to targets (Lambda, Step Functions, SQS, SNS, API destinations and more). It natively receives events from AWS services (for example " EC2 instance state changed", "S3 object created"), from SaaS partners, and from your applications. Additional features: EventBridge Scheduler (cron and one-time schedules, replacing most "cron on EC2" designs), Pipes (point-to-point integrations with filtering and enrichment), archive and replay, and the Schema Registry.

Choose SNS for topic fan-out with subscription filtering; choose EventBridge for event-pattern routing across AWS, SaaS and application sources, API destinations, or archive/replay. Scheduler is a separate scheduling capability. Both SNS and EventBridge can filter event content.

2.4 Amazon Kinesis Data Streams, and Amazon MQ

  • Kinesis Data Streams is for real-time streaming with ordered shards, multiple consumers reading the same data and replay for the retention period (24 hours by default, up to 365 days). Contrast with SQS, where a worker receives and deletes a message after successful processing; failed processing can cause redelivery rather than stream-style replay.
  • Amazon MQ is managed Apache ActiveMQ or RabbitMQ, chosen when migrating an existing application that uses standard protocols (AMQP, MQTT, OpenWire, STOMP, JMS) without rewriting it. For new cloud-native designs prefer SQS/SNS.
Need Service
Buffer work, one consumer group, retry and DLQ SQS
One event to many subscribers SNS (fan-out)
Route events by content, SaaS and AWS service events, schedules EventBridge
Ordered real-time stream, multiple readers, replay Kinesis Data Streams
Existing JMS/AMQP/MQTT application Amazon MQ

3. Amazon API Gateway

API Gateway creates, publishes, secures and monitors APIs at any scale.

API type Best for Notes
REST API Full feature set API keys and usage plans, request validation, caching, WAF, resource policies, private APIs
HTTP API Cheaper, lower latency proxies to Lambda or HTTP backends JWT authorizers, fewer features
WebSocket API Two-way real-time communication (chat, dashboards) Route selection by message content

Key capabilities:

  • Authorization: IAM (SigV4), Amazon Cognito user pool authorizers, Lambda authorizers (custom logic), and JWT authorizers for HTTP APIs.
  • Throttling: account-level limits and per-stage or per-method limits protect backends; usage plans with API keys meter individual clients and apply best-effort throttling and quotas, which clients can exceed; they are not strict spending or access controls. API keys are for tracking and quotas, not for authentication.
  • Caching of responses on REST APIs (TTL default 300 seconds) lowers backend load.
  • Edge-optimized, Regional and private endpoints; AWS WAF attaches to REST APIs.
  • Integration timeout: the common REST API default is 29 seconds; Regional/private REST APIs can request an increase with quota trade-offs, while HTTP APIs have a 30-second maximum. Long jobs should return an acknowledgement and process asynchronously (SQS or Step Functions).
  • A common serverless pattern is API Gateway to Lambda to DynamoDB. Another is API Gateway direct service integration with SQS or Step Functions, with no Lambda in between.

4. Orchestrating with AWS Step Functions

Step Functions coordinates distributed work as a state machine defined in Amazon States Language: Task, Choice, Parallel, Map, Wait, Retry/Catch error handling. Benefits: built-in retries and error paths, visual history, no custom orchestration code.

Workflow type Duration Delivery semantics Typical use
Standard Up to 1 year Exactly-once workflow execution except configured retries; full history Order fulfillment, human approval, long ETL
Express Up to 5 minutes At-least-once (or at-most-once for synchronous) High-volume event processing, streaming transformations

Step Functions avoids synchronous function chains, billed waiting and hidden failures. Lambda durable functions support checkpointed, code-first executions lasting up to one year, with waits between invocations. They do not turn an ordinary Lambda invocation into an arbitrary-length uninterrupted process. Use Step Functions for a visual, service-integrated state machine. In either model, retries of payments or other external side effects need idempotency keys.

5. Containers on AWS

Service What it is Notes
Amazon ECR Private container image registry Image scanning, lifecycle policies, replication
Amazon ECS AWS-native container orchestrator Simple, deep AWS integration, no control plane fee
Amazon EKS Managed Kubernetes control plane Choose for Kubernetes portability, existing K8s tooling or multi-cloud strategy
AWS Fargate Serverless compute engine for ECS and EKS No servers to manage; pay for vCPU and memory per task or pod
EC2 launch type You manage the container instances Needed for GPUs or specific instance types, daemon sets, large steady-state fleets that exploit Savings Plans or Spot
AWS App Runner Managed web apps from source or image for existing customers Closed to new customers; evaluate ECS Express Mode for new deployments
Amazon ECS Express Mode Automated Fargate service, ALB, networking and scaling from a container image and IAM roles Simplifies deployment while keeping resources in your account

Concepts for ECS: a task definition describes containers; a service keeps the desired number of tasks running behind a load balancer; task roles give the containers IAM permissions (the task execution role pulls images and writes logs). Scale services with Service Auto Scaling (target tracking on CPU, memory or ALB request count per target), and the capacity with capacity providers (Fargate, Fargate Spot, EC2 Auto Scaling groups). On EKS, the Cluster Autoscaler or Karpenter adds nodes and the Horizontal Pod Autoscaler adds pods.

Microservices fit containers well: each service has its own deployment, scaling and data store. Use an Application Load Balancer with path-based or host-based routing to send /orders and /payments to different target groups.

6. AWS Lambda

Lambda runs code in response to events without managing servers in its default compute model. The following limits describe ordinary functions unless stated otherwise.

Property Value to remember
Maximum duration 15 minutes per ordinary invocation; eligible Managed Instances asynchronous/event-source invocations can run up to 90 minutes
Memory 128 MB to 10,240 MB; CPU scales with memory
Ephemeral storage (/tmp) 512 MB to 10,240 MB
Deployment package 50 MB zipped (direct upload), 250 MB unzipped, or container image up to 10 GB
Concurrency Default account quota 1,000 per Region (adjustable; new accounts can start lower)
Pricing Per request and per millisecond of duration (memory-weighted)

Features that appear on the exam:

  • Reserved concurrency guarantees and caps a function's share of the account concurrency (it protects downstream systems and other functions). Provisioned concurrency keeps execution environments warm to remove cold starts for latency-sensitive paths. SnapStart speeds up cold starts for supported runtimes such as Java.
  • Event sources: synchronous (API Gateway, ALB), asynchronous (S3, SNS, EventBridge) with retries and an on-failure destination or DLQ, and poll-based event source mappings (SQS, Kinesis, DynamoDB Streams). For SQS, Lambda polls and scales consumers automatically; use partial batch responses so that one bad message does not retry the whole batch.
  • Lambda in a VPC gets ENIs in your subnets to reach private resources (use VPC endpoints or a NAT gateway for AWS service access).
  • Lambda layers, environment variables (encrypted with KMS), function URLs, and Lambda@Edge / CloudFront Functions for edge logic.
  • Amazon RDS Proxy pools connections so that many concurrent Lambda executions do not exhaust a relational database.

6.1 Choosing a compute model

Requirement Best fit
Event-driven, short tasks (under 15 minutes), unpredictable or spiky load Lambda
Long-running or containerized web services, no server management ECS or EKS on Fargate
Kubernetes standardization EKS
Special hardware (GPU), host-level control, steady load with Reserved pricing ECS/EKS on EC2
Lift-and-shift of an existing app EC2
Simple containerized web app with automated infrastructure ECS Express Mode; App Runner for existing eligible customers

Workload visibility and purpose-built managed services

Use CloudWatch metrics for rates, utilization and alarms; structured logs explain individual failures; distributed traces such as AWS X-Ray connect a request across services and reveal where time is spent. Propagate correlation IDs and instrument application calls; sampling and missing instrumentation limit what a trace proves. Prefer OpenTelemetry instrumentation exporting to X-Ray; the X-Ray SDKs and daemon entered maintenance mode on February 25, 2026.

Example. Checkout p95 rises from 200 ms to 2 seconds while ECS CPU remains low. CloudWatch flags the latency increase, logs identify affected order IDs, and traces show a slow payment dependency. Adding workers before locating that dependency could increase its load. Alarm on business failures as well as infrastructure metrics; latency is useful for diagnosis but is not automatically a proportional target-tracking metric.

Choose an existing managed capability when it satisfies the business need, security constraints and quality target:

Requirement Candidate What must be checked
Sentiment and entities in support tickets Amazon Comprehend Supported language, quality and handling of sensitive text
Spoken audio from course text Amazon Polly Voice/language support, output rights and caching needs
Text and tables from scanned invoices Amazon Textract Document formats and human verification of extracted values
Image or video analysis Amazon Rekognition Supported task, consent and accuracy requirements

Worked choice. A help desk needs ticket sentiment, not model training: evaluate Comprehend against labeled examples, restrict data access and route uncertain results to review. Polly synthesizes speech and cannot replace text classification. Likewise, text-to-speech alone does not require operating a GPU model or a general-purpose generative model.

7. Worked example: absorbing an image-processing spike

Scenario. PhotoLab lets users upload photos through a web app. Each upload triggers resizing and watermarking that takes about 40 seconds and runs on a single EC2 instance behind an ALB. During promotions, uploads jump from 20 to 2,000 per minute, the instance saturates and users see errors. The company wants no lost uploads and the least operational overhead.

Step 1: Spot the coupling. Upload acceptance waits for processing on one fixed instance. Suitable ALB timeouts allow 40-second requests, but do not remove overload or held resources.

Step 2: Separate the phases. Let the browser upload directly to S3 using a presigned URL. An S3 event notification places a message in an SQS standard queue. The queue absorbs the spike and holds messages for up to 14 days.

Step 3: Choose the consumer. The job is 40 seconds, well below 15 minutes, and is event driven, so a Lambda function with an SQS event source mapping is the least operational overhead. Set the queue visibility timeout to at least six times the function timeout plus any batching window, enable a DLQ with maxReceiveCount of at least 5 as AWS recommends, and use partial batch responses. Make processing idempotent using the source object version or a durable job ID.

Step 4: Protect downstream. Set reserved concurrency to a value that does not overwhelm a downstream metadata database, and set a suitable maximum concurrency on the SQS event source mapping. RDS Proxy can pool database connections; it does not cap the number of jobs or database queries.

Why other choices are worse. A larger instance raises a fixed ceiling; CPU scaling reacts after overload and needs warm-up. Queue-based EC2 workers remain valid if Lambda cannot run the code. Direct SNS delivery lacks a worker-controlled pull backlog. Kinesis adds ordering and stream replay that this workload does not require.

8. Worked example: choosing between SNS, SQS and EventBridge

Scenario. Billing, warehouse and analytics must receive each order independently. Billing needs retries; adding fraud detection must not change the publisher.

Solution. Publish OrderPlaced to SNS and subscribe one SQS queue per consumer. Independent backlogs, retry policies and DLQs isolate failures. Add fraud detection by subscribing another queue. Both SNS subscription filters and EventBridge patterns can route high-value orders; EventBridge also integrates multiple AWS/SaaS event sources.

Why not alternatives. Calling the three services synchronously from the order service couples availability and latency. A single shared queue would deliver each message to only one consumer. A direct SNS-to-Lambda subscription can work with SNS delivery retries and Lambda asynchronous error handling, but lacks the independently controlled pull backlog of each SQS queue.

9. Common pitfalls

  • Treating a standard SQS queue as exactly-once or ordered. Use FIFO when order and deduplication matter, and write idempotent consumers anyway.
  • A visibility timeout shorter than the processing time, which causes duplicate processing.
  • Choosing an ordinary Lambda invocation for an uninterrupted job longer than 15 minutes (use Fargate or Batch; split checkpointable work with Step Functions or durable functions).
  • Using API keys as the authentication mechanism.
  • Treating 29 seconds as a universal API Gateway ceiling: it is a REST API default; Regional/private REST APIs can request an increase, with quota trade-offs. Check the API type and configured timeout.
  • Confusing SNS push delivery with an SQS pull backlog. SNS stores messages durably for delivery, retries failures and supports subscription DLQs; FIFO topics also offer optional archive/replay for up to 365 days.
  • Using Kinesis when multiple independent consumers do not need replay or ordering, where SNS plus SQS is simpler.
  • Forgetting RDS Proxy or connection management when many Lambda functions share a relational database.
  • Putting session state on instances, which breaks horizontal scaling and failover.

10. Exam tips

  • "Decouple" or "buffer" or "do not lose messages": SQS. "Multiple subscribers": SNS or EventBridge. "Order and duplicates matter": SQS FIFO.
  • "Workflow with retries, branching and human approval": Step Functions.
  • "Least operational overhead for containers": Fargate. "Kubernetes": EKS.
  • "Cold starts hurt the latency": provisioned concurrency (or SnapStart for Java).
  • "Scale on backlog": Auto Scaling on SQS queue depth per instance.
  • "Throttle or meter API consumers": API Gateway usage plans; "cache API responses": API Gateway cache.
  • "Run on a schedule without servers": EventBridge Scheduler triggering Lambda.

11. Mini case study (with solution)

Scenario. ParcelNow needs a metered customer API, independent retries for three-minute label jobs, email/SMS and analytics, plus a monthly four-hour container settlement job. The team wants to reuse Kubernetes manifests with minimal server management.

Solution.

  1. Expose the API with Amazon API Gateway (REST API), Cognito authorizer for customers, usage plans per customer for best-effort throttling and quotas, and AWS WAF in front.
  2. Publish ShipmentCreated to an SNS topic with SQS queues per consumer: label generation (Lambda, 3 minutes is below the limit), notification (Lambda calling SNS for SMS and SES for email) and analytics (a consumer writing to Amazon Data Firehose). Each queue has a DLQ. A direct SNS-to-Firehose subscription is another option, but is a different path without that analytics SQS queue.
  3. The uninterrupted monthly 4-hour container job exceeds an ordinary Lambda invocation's limit: run it as a Step Functions workflow launching Fargate tasks, triggered by EventBridge Scheduler.
  4. Because the team uses Kubernetes manifests, host the microservices on Amazon EKS with Fargate profiles (or EC2 managed node groups where they need GPUs), with compatible workloads on Fargate avoiding worker-node patching. EC2 managed node groups still require node-image updates and maintenance.
  5. Keep session data in DynamoDB or ElastiCache so any pod can serve any request.

Why not alternatives. API keys do not authenticate customers. Ordinary Lambda cannot run this uninterrupted job; ECS does not reuse Kubernetes manifests; one shared queue lacks fan-out.

12. Glossary

  • Loose coupling: components interact through intermediaries so that one can change or fail without breaking the others.
  • Idempotent: processing the same message twice has the same effect as processing it once.
  • Visibility timeout: period during which a received SQS message is hidden from other consumers.
  • Dead-letter queue (DLQ): queue that receives messages that repeatedly fail processing.
  • Fan-out: delivering one message to many consumers.
  • Event bus: router that matches events to rules and delivers them to targets.
  • State machine: Step Functions workflow definition.
  • Fargate: serverless compute for containers.
  • Cold start: extra latency while Lambda initializes a new execution environment.
  • Reserved / provisioned concurrency: Lambda settings for guaranteed capacity and pre-warmed environments.

13. Summary checklist

  • I can explain why queues, topics and events reduce coupling and how stateless compute scales out.
  • I know SQS standard versus FIFO, visibility timeout, long polling, DLQ and the queue-depth scaling pattern.
  • I can choose between SQS, SNS, EventBridge, Kinesis and Amazon MQ.
  • I know API Gateway types, authorizers, throttling, caching and type-specific integration timeouts.
  • I can pick Step Functions (Standard or Express) for orchestration.
  • I can choose between Lambda, Fargate, ECS on EC2 and EKS, and recall Lambda's main limits and concurrency controls.

For the capacity side of this design, continue with AWS compute selection and Auto Scaling. Combine decoupling with Multi-AZ resilience and disaster recovery, and size pooled connections using database replicas, caches, and RDS Proxy.

Sources