Microservices Architecture

A microservice is a service that implements a single business capability, runs in its own process, owns its own data store, and can be deployed independently of every other service. All three properties are required. A service that shares a database with another service cannot be deployed independently: a schema change in one service breaks the other. A service that handles both user authentication and order fulfilment violates the single business capability constraint.

The term was defined in a 2014 article by Martin Fowler and James Lewis. Before that, the same approach existed under various names: service-oriented architecture (SOA), fine-grained services, and component services. The defining distinction from SOA is the emphasis on independent deployability and data ownership rather than shared enterprise service buses.

Netflix operated 700 microservices by 2012. Amazon operates tens of thousands. At that scale, the organisational benefit is as important as the technical one: teams own their services end-to-end and release independently. Conway's Law states that systems mirror their organisation's communication structures. Microservices only deliver their benefits when team boundaries match service boundaries.

The architecture spectrum runs from a monolith at one end to fully distributed microservices at the other, with the modular monolith in between. The right choice depends on team size, deployment frequency, and domain clarity.

A monolith deploys as a single unit. All code is in one repository, sharing a single database. Changes anywhere require a full deployment. Shopify, the e-commerce platform with over 10,000 engineers and billions in annual revenue, runs on a Rails monolith they call the “Shopify Monolith”. They manage complexity through modular design within the single codebase, not through service decomposition.

A modular monolith is a single-process application with strong internal boundaries. Modules communicate through explicit APIs, not direct function calls across domain lines. It deploys as one unit but the internal structure prevents the coupling that makes monoliths painful to evolve. Martin Fowler calls this the “majestic monolith” when the modular discipline is maintained.

Microservices deliver their benefits when independent teams need to release at different velocities, when components have dramatically different scaling requirements, or when technology diversity is genuinely required. They carry the full cost of distributed systems: network failures, distributed transactions, and observability complexity. Both Netflix and Amazon paid those costs deliberately because the organisational benefits at their team sizes justified them.

In a microservices system of 700 services, no service knows the network address of any other service at compile time. Instances scale up, scale down, and restart continuously. Service discovery solves this: each service registers its address with a registry on startup and queries the registry to find other services by name. Netflix built Eureka for this. Kubernetes provides DNS-based discovery natively. HashiCorp Consul is the most widely used solution outside Kubernetes.

A service mesh is the infrastructure layer that manages service-to-service communication. It provides: mutual TLS between services (encrypted and authenticated), traffic routing and load balancing, circuit breaker enforcement, retry policies, and distributed tracing. Istio and Linkerd are the two dominant service meshes for Kubernetes. The mesh deploys as a sidecar proxy (typically Envoy) alongside each service instance, intercepting all network traffic without requiring application-layer changes.

Before the service mesh concept existed, Netflix implemented all these concerns as libraries: Hystrix for circuit breaking, Ribbon for client-side load balancing, Eureka for discovery. The service mesh abstracts these concerns out of the application entirely. A Go service and a Java service can participate in the same mesh with identical policies, without either language needing to implement the resilience logic.

The most operationally challenging aspect of microservices is data management. Each service owns its own database, which means operations that would be a single transaction in a monolith become distributed operations across multiple services.

Consider an order placement: the Order Service creates an order record, the Inventory Service reserves the items, and the Payment Service charges the card. In a monolith, these are three rows in a single ACID transaction: either all succeed or all roll back. In microservices, each step is a separate database write in a separate service. If the Payment Service fails after Inventory has reserved the items, the system is in an inconsistent state.

The saga pattern solves this. A saga is a sequence of local transactions, each publishing an event that triggers the next step. If any step fails, compensating transactions undo the completed steps. The Inventory Service publishes an ItemsReserved event. If Payment fails, it publishes a PaymentFailed event, and the Inventory Service listens for it to execute the compensating ReleaseReservation transaction.

Sagas accept eventual consistency: the system is briefly inconsistent during the transaction. This is a deliberate trade-off. Distributed ACID transactions (via two-phase commit) preserve immediate consistency but are slower, harder to scale, and create coordination coupling between services. Most real-world microservices systems accept eventual consistency with sagas.

DORA (DevOps Research and Assessment) metrics are the standard way to measure software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. In high-performing organisations that deploy multiple times per day, microservices are a frequent architectural pattern. But the correlation is not causal: the organisations that deploy microservices successfully do so because they first built the engineering capability.

Netflix at 700 services manages: 700 separate CI/CD pipelines, 700 separate deployment configurations, distributed tracing across all inter-service calls, on-call rotations for each service, and capacity planning for each service independently. Each of those operational concerns multiplies linearly with the number of services.

Sam Newman's guideline, drawn from working with hundreds of organisations, is that a team should be able to explain why they need microservices before adopting them. The specific pain points that justify the cost are: independent deployment speed across multiple teams, significantly different scaling requirements per component, or mandatory technology diversity. Adopting microservices for future flexibility, because it is fashionable, or because it is what large companies do, almost always produces a distributed monolith with no autonomy benefit.