SkarpChapter 11 of 26
Scalable and Loosely Coupled Architectures on AWS
Move beyond single-tier stacks and design decoupled systems that scale gracefully under unpredictable load using native AWS services.
From Monoliths to Scalable, Loosely Coupled Systems
Why This Module Matters
You are moving beyond simple single-tier stacks to architectures that can absorb unpredictable load without breaking, a key part of the Solutions Architect – Associate exam.
What Is Scalability?
A scalable architecture can handle increased load by adding or enlarging resources. AWS strongly favors horizontal scaling (more instances) over vertical scaling (bigger instances).
What Is Loose Coupling?
Loosely coupled systems minimize direct dependencies between components, often by using queues, topics, and events so each part can fail, restart, or scale independently.
Link to Reliability
Loose coupling and horizontal scaling align with the AWS Well-Architected Framework and make it easier to meet SLAs, RTO, and RPO requirements for resilient workloads.
Core AWS Building Blocks for Scalable Architectures
Think in Building Blocks
Exam questions often ask: given a requirement, which AWS service is the right building block to scale or decouple the system?
Traffic Distribution
Elastic Load Balancing spreads incoming traffic across multiple targets. Use Application Load Balancer for HTTP/HTTPS and routing, Network Load Balancer for extreme performance.
Scaling Compute
Amazon EC2 Auto Scaling adds or removes instances in an Auto Scaling group. Lambda and Fargate provide serverless, naturally scalable compute options.
Data and Messaging
RDS, DynamoDB, and ElastiCache handle scalable data. SQS, SNS, and EventBridge provide queues, pub/sub, and event routing for loose coupling.
Stateless Application Design and Session Management
What Is Stateless?
A stateless component does not rely on local, persistent state between requests, so any instance can handle any request and be replaced at any time.
Stateful Traps
Common mistakes: storing sessions in server memory, saving uploads to instance disks, or using in-memory job queues tied to a single process.
Externalize State
Move sessions to ElastiCache or DynamoDB, store files in S3, and send background work to SQS or EventBridge so workers can scale independently.
Immutable Instances
Treat instances and containers as disposable. Configuration comes from user data or parameter stores, not manual changes on servers.
Example: Scaling a Stateless Web Tier Behind an ALB
Original Problem
A startup runs a monolithic app and database on one EC2 instance. Marketing spikes cause slow performance and occasional crashes.
Step 1: Separate Tiers
Move the database to Amazon RDS Multi-AZ. EC2 instances now only run the web and application logic, not the database.
Step 2–3: ALB and Statelessness
Place an Application Load Balancer in front of multiple EC2 instances and move sessions to ElastiCache and files to S3 to make the app stateless.
Step 4–5: Auto Scaling and Caching
Use an Auto Scaling group to add or remove instances based on CPU, and add CloudFront to cache static content and offload the ALB.
Asynchronous Messaging with SQS and SNS
Why Asynchronous Messaging?
Instead of one service calling another and waiting, the producer sends a message and moves on. This smooths spikes and prevents cascading failures.
Amazon SQS Basics
SQS is a queue that decouples producers and consumers. It offers at-least-once delivery and supports Standard and FIFO queues.
Amazon SNS Basics
SNS is a pub/sub service where publishers send to a topic, and SNS fans out messages to many subscribers like SQS, Lambda, email, or HTTP.
Choosing SQS vs SNS
Use SQS for durable buffering between producer and workers. Use SNS when you need to fan out a message to multiple independent subscribers.
Example: Decoupling a Payment Flow with SQS and SNS
Original Checkout Problem
Checkout calls the payment processor synchronously. Under heavy load, the processor slows down and causes user timeouts.
Step 1–2: Queue and Workers
Checkout writes an order message to SQS and returns quickly. A worker fleet consumes from SQS and calls the payment gateway asynchronously.
Step 3: Scaling by Queue Depth
CloudWatch monitors SQS queue length. Auto Scaling adds more workers when there are many visible messages waiting to be processed.
Step 4: SNS Fan-out
On successful payment, a worker publishes to an SNS topic that triggers email, inventory, and analytics services via different subscribers.
Event-Driven Architectures with EventBridge and Lambda
What Is Event-Driven Design?
In event-driven systems, services emit events like OrderPlaced, and other services subscribe to and react to those events asynchronously.
EventBridge Basics
Amazon EventBridge is an event bus that receives events from AWS services, SaaS apps, and your apps, and routes them to targets using rules.
Benefits for Loose Coupling
Producers do not know consumers. You can add new consumers, each scaling independently, without changing event producers.
Exam Tip
If many independent systems must react to changes, or you need flexible routing based on event content, think EventBridge and possibly Step Functions.
Monoliths vs Microservices on AWS
Monolith Basics
A monolithic app is a single deployable unit with many capabilities. It is simple to start but hard to scale and change as it grows.
Microservices Basics
Microservices split a system into small, independently deployable services, each with its own data and clear bounded context.
AWS Support
Monoliths use ALB, Auto Scaling groups, RDS, ElastiCache. Microservices often use Lambda or ECS, API Gateway, DynamoDB, SQS, SNS, and EventBridge.
Exam Trade-offs
Choose microservices when you need independent scaling and deployments. Beware of a single shared database that tightly couples all services.
Design Exercise: Smoothing Spiky Workloads
Work through this scenario to practice applying asynchronous and stateless patterns.
Scenario: A news website runs a "breaking news" alert feature. When editors publish an alert, the system sends push notifications and emails to millions of subscribers. Currently, a single backend service sends all notifications synchronously. During big stories, the service becomes overloaded and crashes.
Your task: sketch (mentally or on paper) a new architecture on AWS that:
- Keeps the alert publishing experience fast for editors.
- Can handle sudden spikes to millions of notifications.
- Minimizes coupling between the content management system (CMS) and notification channels.
Guiding questions:
- Where can you introduce SQS queues to buffer work?
- Would SNS or EventBridge be better as the central fan-out mechanism, and why?
- Which parts can be run on Lambda versus EC2/ECS?
- How would you make each worker stateless?
Suggested answer structure (do not peek until you have tried):
- Step 1: Describe how the CMS publishes an alert without doing heavy work.
- Step 2: Show how notifications are fanned out to email, mobile push, and possibly other consumers.
- Step 3: Explain how each channel scales independently.
After you have an answer, compare it to a typical pattern: CMS writes an "AlertPublished" event to SNS or EventBridge, which fans out to SQS queues per channel. Lambda or ECS workers pull from each queue and send notifications, scaling based on queue depth.
Quiz 1: Statelessness and Scaling
Test your understanding of stateless design and horizontal scaling.
An application runs on EC2 instances behind an Application Load Balancer. Users report that whenever an instance is terminated by Auto Scaling, they are logged out and lose their shopping cart. What is the BEST design change to enable safe horizontal scaling?
- Enable sticky sessions on the Application Load Balancer so users always return to the same instance.
- Increase the size of each EC2 instance so Auto Scaling rarely needs to terminate instances.
- Store user session and cart data in ElastiCache or DynamoDB instead of instance memory.
- Move the application to a single, larger EC2 instance with higher network performance.
Show Answer
Answer: C) Store user session and cart data in ElastiCache or DynamoDB instead of instance memory.
The problem is that user state is stored on individual instances, making the app stateful. To support safe horizontal scaling, externalize session and cart data to a shared store such as ElastiCache or DynamoDB so any instance can serve any user. Sticky sessions (option A) reduce flexibility and do not fully solve instance termination issues. Scaling up or using a single larger instance (options B and D) do not address the core statelessness requirement and reduce resilience.
Quiz 2: Choosing SQS, SNS, or EventBridge
Practice selecting the right decoupling service.
A company has a billing system that must notify several independent systems whenever an invoice is generated: email notifications, accounting, analytics, and a third-party tax service. New consumers may be added later without changing the billing system. What is the MOST appropriate design?
- Billing system writes invoice records directly to a shared RDS database that all consumers query.
- Billing system sends messages to an SQS queue that all consumers poll from.
- Billing system publishes an event to an SNS topic, and each consumer subscribes via its own protocol or SQS queue.
- Billing system makes synchronous REST API calls to each consumer service in sequence.
Show Answer
Answer: C) Billing system publishes an event to an SNS topic, and each consumer subscribes via its own protocol or SQS queue.
This is a classic fan-out, publish/subscribe scenario where the producer should not know about all consumers. SNS is designed for this: the billing system publishes to an SNS topic, and each consumer subscribes via email, HTTP, Lambda, or its own SQS queue. A shared database couples services and adds polling overhead. A single SQS queue is not ideal for multiple independent consumers. Synchronous REST calls create tight coupling and reduce resilience.
Key Terms Review
Flip these cards to reinforce core concepts before you move on.
- Stateless application tier
- An application layer where no user-specific or request-specific state is stored on individual instances between requests. State such as sessions, files, and queues is externalized to shared services like ElastiCache, DynamoDB, or S3, enabling safe horizontal scaling.
- Loose coupling
- A design approach where components minimize direct dependencies on each other, often by communicating via queues, topics, or events. Each component can evolve, scale, or fail independently without bringing down the whole system.
- Amazon SQS Standard vs FIFO queues
- Standard queues offer high throughput with at-least-once delivery and best-effort ordering. FIFO queues preserve strict first-in-first-out ordering with exactly-once processing semantics and support message groups, but with lower throughput.
- Amazon SNS
- A fully managed publish/subscribe messaging service where publishers send messages to a topic and SNS fans them out to multiple subscribers such as SQS queues, Lambda functions, HTTP endpoints, email, or SMS.
- Amazon EventBridge
- An event bus service that receives events from AWS services, SaaS partners, and custom applications, and uses rules to route events to targets like Lambda, SQS, SNS, Step Functions, and Kinesis based on event patterns.
- Horizontal scaling
- Increasing capacity by adding more instances of a resource, such as additional EC2 instances in an Auto Scaling group or more Lambda invocations, rather than increasing the size of a single instance.
- Microservices architecture
- An architectural style where a system is built from many small, independently deployable services, each with a well-defined responsibility and usually its own data store, communicating via APIs and messaging.
- Back-pressure via queues
- A pattern where a queue such as SQS absorbs bursts of work, allowing consumers to process messages at their own pace. Queue depth can be used to trigger Auto Scaling, preventing overload of downstream systems.
Key Terms
- Amazon SNS
- Amazon Simple Notification Service, a fully managed publish/subscribe messaging service for sending messages to multiple subscribers via topics.
- Amazon SQS
- Amazon Simple Queue Service, a fully managed message queuing service that enables decoupling and buffering between producers and consumers using Standard or FIFO queues.
- Microservices
- An architectural approach where an application is composed of small, independent services that communicate over APIs or messaging, each focusing on a specific business capability.
- Loose coupling
- A design principle in which system components have minimal knowledge of and dependencies on each other, typically communicating via asynchronous messaging or well-defined interfaces.
- Amazon EventBridge
- A serverless event bus service that ingests events from various sources and routes them to targets based on event patterns, supporting event-driven architectures.
- Auto Scaling group
- A logical group of EC2 instances managed together for scaling and health checks, enabling automatic addition or removal of instances based on policies or metrics.
- Horizontal scaling
- Scaling out by adding more instances of a resource (for example, more EC2 instances or containers) instead of increasing the capacity of a single instance.
- Stateless application
- An application design where no persistent user or session state is stored on individual compute instances between requests. All state is offloaded to shared services such as databases, caches, or object storage.