Cheat sheetMS-01

Microservices Fundamentals

Microservices & APIs / Microservices Fundamentals

A microservice is an independently deployable service modeled around a business bounded context that owns its own data. Size is a by-product; boundaries and autonomy are the point.

01
Independent deployabilityRelease one service without lockstep-deploying others. This is the defining trait and forces loose coupling.
02
Bounded contextDraw boundaries around business capabilities; hide the internal model and expose only a stable interface.
03
Own your dataEach service owns its store. Shared tables re-couple services and produce a distributed monolith.
04
Benefits vs costsBuy independent scaling and team autonomy; pay with network failure, distributed debugging, and consistency work.
⚑

Before extracting a service, name the concrete driver (independent scaling, differing release cadence, team autonomy). If you cannot, keep it in the monolith. When you do split, give the new service its own datastore and a stable API - never let others read its tables.

Good splitCatalog becomes its own service with its own DB and a stable API; the catalog team now deploys weekly regardless of the fulfillment freeze.
Anti-patternTwo 'services' still join against the same tables, so a schema change forces a coordinated deploy - a distributed monolith.
Rule of thumb: 'small enough and no smaller'
Test: can I deploy this service alone, today? If not, it is not independent.
Boundary smell: two services always change together -> boundary is wrong
microservicesbounded-contextdeployabilitycouplingddd
review in 6d