Microservices Architecture

What are Microservices?

Microservices is an architectural style where an application is built as a collection of small, independent services that communicate over well-defined APIs. Each service is:

• Independently deployable: Deploy one service without affecting others.
• Loosely coupled: Services interact through APIs, not shared databases.
• Organized around business capabilities: Each service owns a specific domain.
• Owned by small teams: Enables autonomous development and faster iteration.

Example: An e-commerce platform split into User Service, Product Catalog, Order Service, Payment Service, and Notification Service.

Monolith vs Microservices

Core Principles

1. Single Responsibility

Each microservice should do one thing well, aligned with a specific business capability.

Example: Payment Service only handles payment processing—not user authentication or order management.

2. Decentralized Data Management

Each service owns its data. No shared databases between services.

✅ Order Service → Order Database
✅ User Service → User Database
❌ Shared Database for all services

3. Design for Failure

Assume services will fail. Implement resilience patterns like retries, circuit breakers, and fallbacks.

4. Smart Endpoints, Dumb Pipes

Services contain business logic; communication channels (HTTP, messaging) are simple and stateless.

Communication Patterns

Synchronous Communication

• REST APIs: Simple, widely adopted, uses HTTP/JSON.
• gRPC: High-performance, uses Protocol Buffers, ideal for internal services.

GET /api/users/123
Host: user-service.internal

Response:
{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com"
}

Asynchronous Communication

• Message Queues: RabbitMQ, Amazon SQS for task queues.
• Event Streaming: Apache Kafka, AWS Kinesis for real-time event processing.

Best Practice: Use async communication for operations that don't need immediate response (notifications, analytics, order processing).

Key Patterns

API Gateway Pattern

Purpose: Single entry point for all client requests.

Responsibilities:

• Request routing
• Authentication & authorization
• Rate limiting
• Load balancing
• Response aggregation

Tools: Kong, AWS API Gateway, Netflix Zuul, Nginx

Service Discovery

Services need to find each other dynamically in a distributed environment.

Circuit Breaker Pattern

Prevents cascading failures by stopping requests to a failing service.

States:

• Closed: Normal operation, requests flow through.
• Open: Failures exceeded threshold, requests fail immediately.
• Half-Open: After timeout, allow limited requests to test recovery.

Tools: Resilience4j, Hystrix (deprecated), Polly (.NET)

Saga Pattern (Distributed Transactions)

Manages transactions across multiple services without distributed locks.

Data Management Strategies

Database per Service

Each service has its own database, ensuring loose coupling.

User Service     → PostgreSQL (relational data)
Product Service  → MongoDB (flexible schema)
Search Service   → Elasticsearch (full-text search)
Session Service  → Redis (fast key-value access)

Event Sourcing

Store state changes as a sequence of events instead of current state.

Example: Instead of storing "Balance: $100", store events: "Deposit $50", "Withdraw $20", "Deposit $70".

CQRS (Command Query Responsibility Segregation)

Separate read and write models for optimal performance.

Deployment & Infrastructure

Containerization

Package services with their dependencies for consistent deployment.

Dockerfile → Build Image → Push to Registry → Deploy to Kubernetes

Tools: Docker, containerd, Podman

Orchestration

Manage containerized services at scale.

Tools: Kubernetes, Docker Swarm, AWS ECS, Nomad

Observability

The Three Pillars

Distributed Tracing Example

Request ID: abc-123
├── API Gateway (2ms)
├── User Service (15ms)
│   └── User Database (8ms)
├── Order Service (45ms)
│   ├── Inventory Check (12ms)
│   └── Order Database (25ms)
└── Total: 62ms

When to Use Microservices

✅ Good Fit

• Large teams needing independent deployment
• Complex domains with clear boundaries
• High scalability requirements for specific components
• Need for technology diversity

❌ Poor Fit

• Small teams or simple applications
• Startups in early stages (start with monolith)
• Limited DevOps capabilities
• Unclear domain boundaries

Rule of Thumb: Start with a well-structured monolith. Extract microservices when you have clear boundaries and scaling needs.

Summary Table

Interview Tips

• Start with why: Explain the problem microservices solve before diving into patterns.
• Know the trade-offs: Microservices add complexity—discuss when a monolith is better.
• Use concrete examples: Reference real systems (Netflix, Amazon, Uber) and their microservices journeys.
• Discuss data consistency: Explain how you'd handle transactions across services (Saga, eventual consistency).
• Cover observability: Distributed systems need strong logging, metrics, and tracing.
• Connect to CAP theorem: Microservices often trade consistency for availability and partition tolerance.

Microservices enable teams to build scalable, resilient systems by decomposing applications into independent services. Success requires careful design, strong DevOps practices, and clear domain boundaries.