What is Microservices Architecture?

Where the pattern came from

The term "microservices" surfaced in workshops around 2011 and was crystallized in a 2014 essay by Martin Fowler and James Lewis. The underlying ideas had been around for longer — service-oriented architecture in the 2000s, Unix-style small composable programs going back further — but the modern pattern came of age alongside cheap container infrastructure (Docker in 2013, Kubernetes in 2014) that made running fifty separate services operationally tractable. Netflix and Amazon's public engineering writing made it the dominant architectural conversation of the mid-2010s.

What the pattern actually buys you

Three real benefits, in order of how often they actually materialize. First, organizational scale: when 200 engineers are working on one product, splitting into 30 services with clear owners lets each team ship without waiting for the others. Second, technological heterogeneity: a billing service in Java can sit next to a recommendation service in Python without forcing one stack on both. Third, independent scaling: the part of the system under load (image processing, video transcoding) can scale separately from the parts that are idle. None of those benefits are automatic — they require disciplined boundaries — but they are real when earned.

What the pattern actually costs

The hidden bill is large. Every cross-service call is now a network call that can fail, time out, retry, double-deliver, or arrive out of order. Distributed tracing, structured logging, service discovery, retries, circuit breakers, and a deployment pipeline that handles fifty repos instead of one — none of that is optional, and all of it is built by humans before any product feature ships. Data consistency is harder because no single database transaction can span services. Local development is harder because you have to run six services to test one feature.

Sam Newman, who wrote the definitive book on the pattern, has said publicly that most teams that adopted microservices in the 2010s should not have, and many have spent the 2020s walking the decision back. The famous "monolith decomposition" Netflix stories include the parts where Netflix had the engineering budget and need to do it; most companies have neither.

The modular monolith alternative

For most products under a few dozen engineers, a well-modularized monolith — one deployable, multiple internal modules with clean boundaries, one database with logical schemas — gives you 80% of the maintainability benefit at 10% of the operational cost. The modules can become services later, if and when the team and the load demand it. That deferred decision is much cheaper than the reverse migration from a premature microservices mess back to something coherent.

At QUANT LAB

Our default on a new SaaS platform is a modular monolith on Next.js plus Postgres, with strict domain-driven boundaries inside the codebase that would let us extract services later. We split services out only when there is a concrete reason — independently scaled workloads, regulatory isolation, a separate team owning a separate cadence.

Where we do build microservices on day one, it is usually for clients where the team is already large or the workload is genuinely heterogeneous — a trading system with a latency-sensitive matcher in Rust next to a Python research environment, for example. Read the 2026 state of custom software essay for the broader take, or book a call for a one-hour architectural review.