Microservices Architecture on AWS

Overview

Microservices architecture is an approach where a single application is composed of many loosely coupled and independently deployable services.

Architecture Pattern

graph TB
    subgraph "Client Layer"
        UI[Web UI]
    end
    
    subgraph "API Gateway Layer"
        ALB[Application Load Balancer]
        APIG[API Gateway]
    end
    
    subgraph "Service Mesh"
        SM[App Mesh]
    end
    
    subgraph "Microservices"
        MS1[User Service<br/>ECS/Fargate]
        MS2[Order Service<br/>ECS/Fargate]
        MS3[Payment Service<br/>ECS/Fargate]
        MS4[Inventory Service<br/>ECS/Fargate]
        MS5[Notification Service<br/>Lambda]
    end
    
    subgraph "Data Layer"
        DB1[(RDS - Users)]
        DB2[(DynamoDB - Orders)]
        DB3[(ElastiCache)]
        DB4[(RDS - Inventory)]
    end
    
    subgraph "Messaging"
        SQS[SQS]
        SNS[SNS]
        EventBridge[EventBridge]
    end
    
    UI --> ALB
    UI --> APIG
    ALB --> SM
    APIG --> SM
    
    SM --> MS1
    SM --> MS2
    SM --> MS3
    SM --> MS4
    
    MS1 --> DB1
    MS2 --> DB2
    MS2 --> SQS
    MS3 --> DB3
    MS4 --> DB4
    
    SQS --> MS5
    MS5 --> SNS
    EventBridge --> MS5
    
    style UI fill:#e8f5e9
    style ALB fill:#fff3e0
    style MS1 fill:#e3f2fd
    style MS2 fill:#e3f2fd
    style MS3 fill:#e3f2fd
    style MS4 fill:#e3f2fd
    style MS5 fill:#e1bee7

Core Principles

1. Service Independence

Each microservice can be:

• Developed independently
• Deployed independently
• Scaled independently
• Failed independently

2. Decentralized Data Management

• Each service owns its data
• No shared databases
• Data consistency via events

3. API-First Design

• Well-defined service contracts
• Versioned APIs
• Backward compatibility

AWS Services for Microservices

Communication Patterns

Synchronous Communication

sequenceDiagram
    participant Client
    participant API Gateway
    participant Service A
    participant Service B
    
    Client->>API Gateway: Request
    API Gateway->>Service A: Forward Request
    Service A->>Service B: HTTP/gRPC Call
    Service B-->>Service A: Response
    Service A-->>API Gateway: Response
    API Gateway-->>Client: Response

Asynchronous Communication

sequenceDiagram
    participant Service A
    participant EventBridge
    participant SQS Queue
    participant Service B
    participant Service C
    
    Service A->>EventBridge: Publish Event
    EventBridge->>SQS Queue: Route Event
    EventBridge->>Service C: Direct Invocation
    Service B->>SQS Queue: Poll Messages
    SQS Queue-->>Service B: Deliver Message

Implementation Example

Service Definition (ECS Task)

Copy
1interface MicroserviceConfig {
2  name: string;
3  image: string;
4  cpu: number;
5  memory: number;
6  environment: Record<string, string>;
7  ports: number[];
8}
9
10const userServiceConfig: MicroserviceConfig = {
11  name: 'user-service',
12  image: 'user-service:latest',
13  cpu: 256,
14  memory: 512,
15  environment: {
16    DB_HOST: 'user-db.cluster.region.rds.amazonaws.com',
17    CACHE_ENDPOINT: 'redis.cache.amazonaws.com',
18    SERVICE_MESH_ENABLED: 'true'
19  },
20  ports: [3000]
21};

Service Communication

Copy
1// Using AWS SDK for service-to-service communication
2import { ServiceDiscovery } from 'aws-sdk';
3
4class ServiceClient {
5  async callService(serviceName: string, endpoint: string, data: any) {
6    // Discover service instance
7    const serviceUrl = await this.discoverService(serviceName);
8    
9    // Make HTTP request with retry logic
10    const response = await fetch(`${serviceUrl}${endpoint}`, {
11      method: 'POST',
12      headers: {
13        'Content-Type': 'application/json',
14        'X-Trace-Id': generateTraceId()
15      },
16      body: JSON.stringify(data)
17    });
18    
19    return response.json();
20  }
21  
22  private async discoverService(serviceName: string): Promise<string> {
23    // AWS Cloud Map service discovery
24    const discovery = new ServiceDiscovery();
25    const instances = await discovery.discoverInstances({
26      NamespaceName: 'microservices',
27      ServiceName: serviceName
28    }).promise();
29    
30    return instances.Instances[0].Attributes.AWS_INSTANCE_IPV4;
31  }
32}

Data Management Patterns

1. Database per Service

graph LR
    A[User Service] --> B[(User DB)]
    C[Order Service] --> D[(Order DB)]
    E[Payment Service] --> F[(Payment DB)]
    
    style A fill:#e3f2fd
    style C fill:#e3f2fd
    style E fill:#e3f2fd
    style B fill:#f3e5f5
    style D fill:#f3e5f5
    style F fill:#f3e5f5

2. Event Sourcing

graph LR
    A[Service] --> B[Event Store]
    B --> C[Event 1: User Created]
    B --> D[Event 2: Profile Updated]
    B --> E[Event 3: Email Verified]
    
    C --> F[Read Model 1]
    D --> F
    E --> F

3. CQRS Pattern

graph TB
    A[Command] --> B[Write Model]
    B --> C[Event Bus]
    C --> D[Read Model 1]
    C --> E[Read Model 2]
    F[Query] --> D
    F --> E
    
    style A fill:#ffcdd2
    style B fill:#f8bbd0
    style C fill:#e1bee7
    style D fill:#c5cae9
    style E fill:#c5cae9
    style F fill:#b2dfdb

Service Deployment

Container Deployment (ECS)

Copy
1# docker-compose.yml for ECS
2version: '3'
3services:
4  user-service:
5    image: user-service:latest
6    ports:
7      - "3000:3000"
8    environment:
9      - DB_HOST=user-db
10      - REDIS_HOST=redis
11    deploy:
12      replicas: 3
13      resources:
14        limits:
15          cpus: '0.5'
16          memory: 512M

Best Practices

Design Principles

1. ✅ Single Responsibility: Each service does one thing well
2. ✅ Loose Coupling: Minimize dependencies between services
3. ✅ High Cohesion: Related functionality stays together
4. ✅ Autonomous: Services are independently deployable
5. ✅ Observable: Built-in logging, metrics, and tracing

Operational Excellence

• Containerization: Use Docker for consistency
• CI/CD Pipeline: Automated testing and deployment
• Service Discovery: Dynamic service registration
• Health Checks: Liveness and readiness probes
• Circuit Breakers: Prevent cascade failures

Security

graph TD
    A[WAF] --> B[ALB]
    B --> C[Service Mesh]
    C --> D[mTLS]
    D --> E[IAM Roles]
    E --> F[Service]
    F --> G[Secrets Manager]
    
    style A fill:#ffcdd2
    style D fill:#ffcdd2
    style E fill:#ffcdd2
    style G fill:#ffcdd2

Monitoring Strategy

Observability Pillars

1. Logging

   • Centralized logging with CloudWatch
   • Structured logging format
   • Correlation IDs across services

2. Metrics

   • Service-level metrics
   • Business metrics
   • Infrastructure metrics

3. Tracing

   • Distributed tracing with X-Ray
   • Request flow visualization
   • Performance bottleneck identification

Challenges and Solutions

Cost Optimization

• Use Fargate for serverless container management
• Implement auto-scaling policies
• Leverage spot instances for non-critical services
• Use caching strategically (ElastiCache)
• Optimize container sizes and resource allocation

Related Patterns

• Serverless Pattern
• Event-Driven Design
• Service Mesh Pattern