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

graph TD
  subgraph Monolith["Monolith - single deployable unit, single database"]
    Mods["Users, Orders, Pays, Notify modules"] --> MDB["Single Database"]
  end
  subgraph Microservices["Microservices - each owns its DB, deploys independently"]
    UserS["User Service"] --> UserDB["User DB"]
    OrderS["Order Service"] --> OrderDB["Order DB"]
    PayS["Payment Service"] --> PayDB["Pay DB"]
  end

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.

graph TD
  UC["User Context: Registration, Profile, Auth"]
  OC["Order Context: Cart, Checkout, Order history"]
  IC["Inventory Context: Stock levels, Warehouses, Suppliers"]
  PC["Payment Context: Processing, Refunds, Invoices"]
  NC["Notification Context: Email, SMS, Push"]
  title["E-Commerce Platform Bounded Contexts"]

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.

graph LR
  A["Service A"] -->|"HTTP/gRPC"| B["Service B"]
  B -->|"Response"| A

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

Asynchronous Communication

Services communicate via message queues or event buses.

graph LR
  A["Service A"] -->|"Event"| Bus["Event Bus"]
  Bus -->|"Event"| B["Service B"]

Pros: Loose coupling, resilience, scalability. Cons: Eventual consistency, harder to debug, message ordering.

When to Use Each