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 they actually make sense

Microservices solve organizational and operational scale problems (dozens of teams, parts of the system with very different load). They are not a higher maturity level: for most products, a Modulith gives 80% of the benefit at a fraction of the cost. Teams like Amazon Prime Video have published that they moved part of their system from distributed services back to a monolith because of cost and complexity.

Before splitting into services, you should be able to answer yes to most of these:

  1. Do teams step on each other at deploy time and cannot coordinate?
  2. Is there a measured bottleneck that can only be solved by scaling one component on its own?
  3. Are the bounded contexts stable (boundaries don't change every sprint)?
  4. Do we have mature CI/CD, observability and on-call?
  5. Does the budget cover infrastructure and platform staff?

If not, start with the Modulith. See the comparison.

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