Mastering Distributed Design Patterns in AWS

This guide explores the architectural principles required to build resilient, scalable, and highly available systems on AWS, focusing on the transition from monolithic to distributed microservices.

Learning Objectives

By the end of this study guide, you should be able to:

• Differentiate between monolithic and microservices architectures.
• Design loosely coupled systems using messaging services like Amazon SQS and SNS.
• Evaluate scaling strategies (Horizontal vs. Vertical) based on application requirements.
• Select appropriate Disaster Recovery (DR) strategies based on RPO and RTO needs.
• Implement the principles of statelessness and immutable infrastructure.

Key Terms & Glossary

• Loose Coupling: An approach where components are independent, so a change in one does not require changes in others.
• Microservices: An architectural style that structures an application as a collection of small, autonomous services modeled around a business domain.
• Statelessness: A design where no data from previous interactions is stored on the server; every request contains all the information needed to process it.
• Idempotency: The property of certain operations in which they can be applied multiple times without changing the result beyond the initial application (critical for distributed retries).
• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time.
• RTO (Recovery Time Objective): The maximum acceptable downtime for a system.

The "Big Idea"

The transition from "Pets to Cattle" defines distributed design. In a monolithic architecture, servers are "pets"—unique, manually configured, and indispensable. In a distributed AWS environment, servers are "cattle"—stateless, interchangeable, and easily replaced. By decoupling components with queues and designing for failure, we create systems that can survive the loss of an entire Availability Zone or Region without manual intervention.

Formula / Concept Box

Hierarchical Outline

• I. Decoupling Architectures
  • Message Queues (SQS): Buffer requests to allow asynchronous processing.
  • Pub/Sub (SNS): Fan-out patterns to trigger multiple downstream actions (e.g., Email + Lambda).
  • API Gateway: Management and throttling of microservice entry points.
• II. Designing for Resilience
  • Multi-AZ Deployment: Protecting against data center failure.
  • Load Balancing: Distributing traffic via Application Load Balancers (ALB).
  • Health Checks: Automatically removing unhealthy instances from rotation.
• III. Data Patterns
  • Read Replicas: Offloading read traffic from the primary database to improve performance.
  • Sharding/Partitioning: Splitting large datasets across multiple database nodes (DynamoDB).
  • Caching: Using CloudFront (Edge) or ElastiCache (In-memory) to reduce latency.
• IV. The 12-Factor App (Distributed focus)
  • Stateless Processes: Execute app as one or more stateless processes.
  • Backing Services: Treat databases/queues as attached resources.
  • Logs as Streams: Treat logs as event streams rather than local files.

Visual Anchors

Decoupling with Amazon SQS

Multi-AZ High Availability

Definition-Example Pairs

• Immutable Infrastructure: The practice of never modifying a server once deployed; instead, replace it with a new version from a fresh image (AMI).
  • Example: Instead of SSH-ing into a server to patch security, you update the Auto Scaling Launch Template and trigger an instance refresh.
• Circuit Breaker Pattern: A design pattern used to detect failures and encapsulate the logic of preventing a failure from constantly recurring during maintenance or temporary external outages.
  • Example: If a third-party payment API is down, the system immediately returns a "Service Unavailable" message rather than waiting 30 seconds for a timeout, saving resources.
• Event-Driven Architecture: A system where the flow is determined by events (changes in state).
  • Example: An image upload to S3 triggers a Lambda function to create a thumbnail automatically.

Worked Examples

Scenario: Handling Spike Traffic for a Video Processing Site

Problem: A website allows users to upload 4K videos for processing. During peak times, the web server crashes because it is trying to process heavy video files while serving users.

Solution using Distributed Patterns:

1. Decouple: Use Amazon SQS. The Web Tier uploads the raw video to S3 and places a message in SQS.
2. Scale: A fleet of EC2 Worker Instances in an Auto Scaling Group monitors the SQS queue depth.
3. Process: As the queue grows, more workers are launched. They process the video and save the result back to S3.
4. Result: The Web Tier stays responsive because it no longer handles the heavy processing logic directly.

Scenario: Global Low-Latency Database Access

Problem: Users in Japan are experiencing 500ms latency when accessing a database hosted in Northern Virginia (US).

Solution:

1. Read Replicas: Deploy an RDS Read Replica in the ap-northeast-1 (Tokyo) region.
2. Route 53: Use Latency-based routing to send Japanese users to the local replica.
3. CloudFront: Cache static assets at Tokyo edge locations to further reduce load times.

Checkpoint Questions

1. What is the main difference between SQS and SNS in a fan-out pattern?
2. Why is "Statelessness" a requirement for effective horizontal scaling?
3. In a Disaster Recovery scenario, which strategy has the lower RTO: Pilot Light or Warm Standby?
4. How does an Application Load Balancer (ALB) handle a failed instance in a target group?
5. What AWS service would you use to orchestrate multiple Lambda functions into a complex workflow?

▶Click to see answers

1. SQS is for 1-to-1 message processing (queuing); SNS is for 1-to-many message distribution (broadcasting).
2. Because any instance in a scaling group must be able to handle any incoming request without needing local session data from previous requests.
3. Warm Standby has a lower RTO because more resources are already running at a smaller scale compared to Pilot Light.
4. The ALB uses Health Checks; if an instance fails, the ALB stops routing traffic to it and redirects it to healthy instances.
5. AWS Step Functions.