Task Statement 2.1: Design scalable and loosely coupled architectures.

📘AWS Certified Solutions Architect – (SAA-C03)

1. What Does This Skill Mean?

You must be able to:

Understand application requirements
Choose the right architecture:
- Event-driven
- Microservices
- Multi-tier
Design systems that are:
- Scalable
- Loosely coupled
- Highly available
- Fault-tolerant

2. Key Concepts You MUST Know

2.1 Scalability

Ability to handle increasing load.

Types:

Vertical scaling → increase instance size
Horizontal scaling → add more instances (preferred in AWS)

AWS services:

Auto Scaling Groups
Elastic Load Balancer

2.2 Loose Coupling

Components do NOT depend directly on each other.

Benefits:

Easier updates
Independent scaling
Failure isolation

Achieved using:

Messaging services
APIs
Events

2.3 High Availability

System continues to work even if some components fail.

Achieved using:

Multi-AZ deployments
Load balancing
Redundancy

3. Event-Driven Architecture

3.1 What Is It?

An architecture where components communicate using events.

An event = something that happens in the system.

Examples in IT:

A file is uploaded
A database record is created
A user submits a form

3.2 How It Works

Event happens
Event is sent to a service
Other services react to it

3.3 AWS Services Used

Amazon SQS → message queue
Amazon SNS → pub/sub notifications
Amazon EventBridge → event routing
AWS Lambda → event processing

3.4 Example (IT Scenario)

A file is uploaded to S3
S3 triggers Lambda
Lambda processes file
Notification sent via SNS

3.5 Benefits

Loose coupling
Scalable
Asynchronous processing
Fault isolation

3.6 Important Exam Points

SQS = queue (pull model)
SNS = pub/sub (push model)
EventBridge = advanced routing
Lambda = serverless compute

4. Microservices Architecture

4.1 What Is It?

Application is divided into small independent services.

Each service:

Has its own logic
Can be deployed independently
Communicates via APIs or events

4.2 Key Characteristics

Independent services
API-based communication
Separate databases (often)
Independent scaling

4.3 AWS Services Used

Amazon ECS / EKS → container orchestration
AWS Lambda → serverless microservices
Amazon API Gateway → expose APIs
AWS Fargate → serverless containers

4.4 Example (IT Scenario)

Authentication service
Payment service
Notification service

Each runs independently and communicates via API Gateway or events.

4.5 Benefits

High scalability
Faster development
Independent deployment
Fault isolation

4.6 Challenges (Exam Important)

Complexity increases
Monitoring is harder
Requires good communication design

5. Multi-Tier Architecture

5.1 What Is It?

Application is divided into layers (tiers).

5.2 Common 3-Tier Architecture

1. Presentation Layer

User interface
Example: Web app

2. Application Layer

Business logic
Example: EC2, Lambda

3. Data Layer

Database
Example: RDS, DynamoDB

5.3 AWS Services Used

Presentation:
- Amazon CloudFront
- S3 (static websites)
- ALB
Application:
- EC2 / ECS / Lambda
Data:
- RDS
- DynamoDB

5.4 Example (IT Scenario)

User accesses web app via CloudFront
Request goes to ALB
ALB sends to EC2 or Lambda
Data stored in RDS

5.5 Benefits

Separation of concerns
Easy scaling per layer
Better security control

6. When to Use Which Architecture

6.1 Event-Driven → Use When:

You need asynchronous processing
Systems react to events
Decoupling is important

Examples:

File processing
Notifications
Data pipelines

6.2 Microservices → Use When:

Large application split into smaller services
Teams work independently
Frequent updates needed

6.3 Multi-Tier → Use When:

Traditional web applications
Clear separation of frontend, backend, database

7. Combining Architectures (VERY IMPORTANT)

In AWS, architectures are often combined.

Example:

Multi-tier + microservices + event-driven

Typical design:

Frontend (S3 + CloudFront)
Backend (Lambda or ECS microservices)
Events (SQS, SNS)
Database (DynamoDB or RDS)

8. Design Best Practices (Exam Critical)

8.1 Use Managed Services

Reduce operational overhead
Example: Lambda, DynamoDB

8.2 Decouple Components

Use SQS, SNS, EventBridge

8.3 Design for Failure

Assume components will fail
Use retries, DLQs (Dead Letter Queues)

8.4 Use Auto Scaling

Handle traffic spikes

8.5 Secure Each Layer

IAM roles
Security groups
Encryption

8.6 Use Caching

Amazon ElastiCache
CloudFront

9. Common Exam Scenarios

Scenario 1:

“System must process tasks asynchronously”
→ Use:

SQS + Lambda

Scenario 2:

“Application must scale independently per feature”
→ Use:

Microservices

Scenario 3:

“Web app with frontend, backend, database”
→ Use:

Multi-tier architecture

Scenario 4:

“Loose coupling required”
→ Use:

Event-driven (SNS/SQS/EventBridge)

10. Key Differences Summary

Architecture	Communication	Coupling	Scaling
Event-driven	Events	Loose	High
Microservices	APIs/events	Loose	Very high
Multi-tier	Layered	Moderate	Layer-based

11. Final Exam Tips

Always choose loosely coupled architecture
Prefer serverless when possible
Use event-driven for async workflows
Use microservices for large, complex apps
Use multi-tier for structured web apps
Remember:
- SNS = push
- SQS = queue
- Lambda = event compute