Full-Stack Architecture Patterns

Chapter 7: Microservices Architecture

7.1 Microservices Concepts

Microservices architecture breaks applications into small, independent services. Each service handles a specific business function.

Microservices Characteristics:

• Independence: Services can be developed, deployed, and scaled independently
• Technology Diversity: Each service can use different technologies
• Fault Isolation: Failure in one service doesn't crash entire system
• Team Autonomy: Small teams own specific services

When to Use Microservices:

• Large, complex applications
• Multiple teams working on different features
• Need for independent scaling
• Different technology requirements
• High availability requirements

Microservices vs Monolith:

• Monolith: Single application, easier to develop, harder to scale
• Microservices: Multiple services, more complex, better scalability
• Start with monolith, extract services as needed

Service Boundaries:

• Define services by business capabilities
• Each service owns its data
• Services communicate via APIs
• Avoid shared databases

7.2 Service Communication

Microservices need to communicate effectively. Choose communication patterns based on requirements.

Synchronous Communication:

• HTTP/REST APIs
• Immediate response required
• Simple to implement
• Can create coupling

// Service A calls Service B
const response = await fetch('http://service-b/api/data');
const data = await response.json();

Asynchronous Communication:

• Message queues (RabbitMQ, Kafka)
• Event-driven architecture
• Better decoupling
• Handles failures gracefully

// Publish event
await messageQueue.publish('user.created', {
    userId: 123,
    email: 'user@example.com'
});

// Subscribe to event
messageQueue.subscribe('user.created', async (event) => {
    // Handle user creation
});

API Gateway:

• Single entry point for clients
• Routes requests to appropriate services
• Handles authentication and rate limiting
• Simplifies client integration

7.3 Service Discovery

Services need to find and communicate with each other.

Service Registry:

• Central registry of available services
• Services register on startup
• Clients query registry for service locations
• Examples: Consul, Eureka, Kubernetes services

Load Balancing:

• Distribute requests across service instances
• Improves availability and performance
• Round-robin, least connections, weighted

7.4 Data Management

Each microservice should own its data.

Database per Service:

• Each service has its own database
• No shared databases
• Prevents tight coupling
• Allows technology diversity

Data Consistency:

• Eventual consistency between services
• Use saga pattern for distributed transactions
• Implement compensation for failures