Microservices

A set of small, autonomous services, each with its own deployment and database, communicating over a network.

Context

An organization with many teams, clear bounded contexts, and operational maturity (CI/CD, observability, on-call), that wants to deploy independently and scale specific parts of its system.

Problem

A monolith couples teams, release cycles, and scaling.

Solution

Small services, aligned with a bounded context, each with its own database, communicating via messages or HTTP.

#Example

CSHARP 
                ┌──────────┐  ┌──────────┐  ┌──────────┐
                │  Orders  │  │ Payments │  │ Shipping │
                │  + DB    │  │   + DB   │  │  + DB    │
                └────┬─────┘  └────┬─────┘  └────┬─────┘
                     └─────── Message Bus ───────┘

#Advantages

  • Autonomous teams.
  • Service-based scaling.
  • Fault isolation.
  • Heterogeneous stacks.

#Real cost

  • Significant DevOps: orchestration (K8s), service mesh, tracing, schema registry.
  • Eventual consistency and compensations (Saga, Outbox).
  • Network latency between components that used to be function calls.
  • Contract versioning.
When NOT to use it
  • Small team (under 20 people) or a product still seeking product-market fit: the operational cost will crush you.
  • Without mature observability or a platform team: you will suffer.
  • If services need to share a lot of data within transactions: you are partitioning the domain incorrectly.
Tradeoffs
Pro Con
Autonomous teams, independent deployment Complex, expensive operations (orchestration, observability)
Granular scaling Latency and network failures everywhere
Isolates failures Eventual consistency
Heterogeneous stacks possible Distributed systems: more bugs and a larger surface to defend

#architecture #microservices #distributed