Microservices Architecture

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services. Each service owns its data and business logic, communicates over well-defined APIs, and can be developed and scaled independently.

---

Monolith vs Microservices

Monolith:                              Microservices:

┌─────────────────────────┐            ┌────────┐  ┌────────┐  ┌────────┐
│                         │            │  User  │  │ Order  │  │Payment │
│  All modules in one     │            │Service │  │Service │  │Service │
│  deployable unit        │            └───┬────┘  └───┬────┘  └───┬────┘
│                         │                │           │           │
│  ┌──────┐ ┌──────┐     │                ▼           ▼           ▼
│  │Users │ │Orders│     │            ┌────────┐  ┌────────┐  ┌────────┐
│  └──────┘ └──────┘     │            │User DB │  │Order DB│  │Pay DB  │
│  ┌──────┐ ┌──────┐     │            └────────┘  └────────┘  └────────┘
│  │Pays  │ │Notify│     │
│  └──────┘ └──────┘     │            Each service owns its own database
│                         │            and can be deployed independently.
│     Single Database     │
└─────────────────────────┘

Comparison

Aspect	Monolith	Microservices
Deployment	All or nothing	Independent per service
Scaling	Scale entire application	Scale individual services
Technology	Single stack	Polyglot (any language/framework)
Team structure	One team or tightly coupled teams	Small, autonomous teams
Complexity	Simpler initially	Distributed systems complexity
Data consistency	ACID transactions	Eventual consistency
Testing	Simpler end-to-end	Contract testing, integration
Fault isolation	One bug can bring down everything	Failures are contained

Tip: Start with a monolith and extract microservices when you have clear, well-understood service boundaries. Premature decomposition is a common mistake.

---

Defining Service Boundaries

The hardest part of microservices is drawing the right boundaries. Apply Domain-Driven Design (DDD) principles:

Bounded Contexts

Each microservice should align with a bounded context — a boundary within which a particular domain model is defined and applicable.

E-Commerce Platform Bounded Contexts:

┌────────────────┐  ┌────────────────┐  ┌────────────────┐
│   User Context │  │  Order Context │  │ Inventory      │
│                │  │                │  │ Context        │
│  - Registration│  │  - Cart        │  │  - Stock levels│
│  - Profile     │  │  - Checkout    │  │  - Warehouses  │
│  - Auth        │  │  - Order history│  │  - Suppliers  │
└────────────────┘  └────────────────┘  └────────────────┘

┌────────────────┐  ┌────────────────┐
│ Payment Context│  │ Notification   │
│                │  │ Context        │
│  - Processing  │  │  - Email       │
│  - Refunds     │  │  - SMS         │
│  - Invoices    │  │  - Push        │
└────────────────┘  └────────────────┘

Signs Your Boundaries Are Wrong

• Services need to make many synchronous calls to each other
• A single change requires deploying multiple services
• Circular dependencies between services
• Services share a database

---

Communication Patterns

Synchronous Communication

Services call each other directly, typically via HTTP/REST or gRPC.

┌────────┐    HTTP/gRPC    ┌────────┐
│Service │────────────────▶│Service │
│   A    │◀────────────────│   B    │
└────────┘    Response     └────────┘

Pros: Simple, real-time response. Cons: Tight coupling, cascading failures, latency adds up.

Asynchronous Communication

Services communicate via message queues or event buses.

┌────────┐    Event     ┌──────────┐    Event     ┌────────┐
│Service │─────────────▶│  Event   │─────────────▶│Service │
│   A    │              │   Bus    │              │   B    │
└────────┘              └──────────┘              └────────┘