Microservices

Why it matters

Microservices are how large engineering organisations ship independently: dozens of teams, each owning services they can deploy without a release train. They are also how teams without those organisational pressures create a distributed monolith that has every cost of distribution and none of the benefits. The architecture is a tool for organisational scale first and technical scale second, and the interview question is whether you know what it costs and how to draw boundaries that pay for themselves.

The idea

A microservices architecture decomposes a system into services that are independently deployable, each owning a slice of the business domain and the data behind it, communicating over the network through explicit contracts (REST, gRPC, events). Each service can be built, tested, deployed, scaled and failed on its own. The architecture trades in-process simplicity for independence.

What you gain

1. 1

   Independent deployment

   A team ships its service on its own schedule. This is the primary benefit and the one that justifies the cost; everything else is secondary.
2. 2

   Independent scaling and runtime

   The image-processing service runs on GPU instances in Go; the catalogue runs on small instances in TypeScript; each scales on its own metric.
3. 3

   Fault isolation

   A crash or leak in recommendations does not take down checkout, provided callers handle its failure (circuit breakers, fallbacks).
4. 4

   Clear ownership

   Each service has a team, an on-call rotation, a contract and a data model it controls.

What you pay

Every in-process call becomes a network call with latency, failure and timeouts. Every cross-service transaction becomes a saga. Every join becomes an API call or a duplicated read model. Debugging needs distributed tracing; deployment needs a platform; testing needs contract tests and environments. Data that was one schema is now many, kept consistent by events. The Distribution stage exists because of this list.

Drawing boundaries

Boundaries should follow the business domain, not technical layers: a service per bounded context (orders, inventory, payments), not a service per layer (a database service, a validation service). Good boundaries have high cohesion inside (things that change together live together) and low coupling across (a change in one rarely requires a change in another). Signs of a bad boundary: two services that always deploy together, chatty synchronous call chains to serve one request, and shared tables.

Database per service

Each service owns its data and no other service reads or writes its tables directly. Sharing a database couples schemas, makes independent deployment impossible and recreates the monolith's coupling with the monolith's advantages removed. Other services get the data through the owner's API or through events the owner publishes, which means accepting duplicated, eventually consistent read models. This rule is what makes the architecture work and the rule most often broken.

The distributed monolith

The platform you need first

Before the first service: continuous delivery pipelines, containers and orchestration, service discovery, centralised logging with correlation ids, metrics and distributed tracing, an API gateway, secrets management, and standard libraries for timeouts, retries and circuit breakers. Teams that skip this build it reactively during incidents. The Microservices patterns module covers the pieces.