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
