Microservices

Split one application into small services that each own their data and can be deployed on their own.

Live modeldata or requestresponsebusy / idle instance

What you’re watchingThe gateway routes each request by path to the service that owns it, and each service answers from its own database. No service reads another’s data directly.

How it works

Instead of one program, the application is a set of services, each built around one business capability (orders, payments, search) and owned by one team. Each runs in its own process, is deployed on its own schedule and keeps its own database; no other service may read that database directly. Services talk over the network: HTTP/JSON or gRPC calls when the caller needs an answer now, and messages through a queue or event bus when it doesn’t. An API gateway usually sits in front, routing each request to the service that owns it. The payoff is independence: a team can ship payments ten times a day without touching search, scale only the service that is hot, and pick a different language or database where it really helps. The costs move to the network and to operations. A call that was a function call now takes milliseconds and can fail or time out. A change that spans two services can no longer sit in one database transaction, so you coordinate it with a saga: a chain of local transactions with compensating steps that undo the earlier ones if a later one fails. Finding why a request was slow needs distributed tracing across services. And every service needs its own pipeline, monitoring, alerts and on-call owner, which is why the style pays off for large organisations and often hurts small ones.

Think of it as

A food court instead of one restaurant kitchen. Each stall has its own staff, menu and fridge, and can change recipes or opening hours without asking the others. A meal that needs dishes from three stalls means three queues, and if one stall runs out, someone has to decide whether to refund the other two.

Reach for it when

Many teams (dozens of engineers or more) are slowing each other down in one codebase and one release
Parts of the system have clearly different load, scaling or uptime needs
Domain boundaries are well understood and stable, often after a monolith has shown where they are
You already have automated deployment, monitoring and tracing, or the budget to build them

Think twice when

A new product or a small team; start with a (modular) monolith
Most features change data in several places at once and need one transaction
Services would call each other in long synchronous chains for every request, so one slow service slows everything

A real example

A shop splits its checkout into Orders, Payments and Inventory services, each with its own database. Placing an order runs a saga: Orders records the order as pending, Payments charges the card, Inventory reserves the items. If Inventory finds an item out of stock, Payments refunds the charge and Orders marks the order cancelled. Each step is a local transaction, and the order is briefly “pending” where a monolith would have used one transaction.

What moves when you split a monolith#

The same work still has to happen; it changes shape and place.

Concern	In a monolith	In microservices
Calling another part	A function call in the same process	A network call (HTTP, gRPC) or a message; it can be slow, fail or time out
Changing data in two places	One database transaction	A saga of local transactions with compensating steps, and a period where data is in between
Finding a slow request	One process, one log, one profiler	Distributed tracing across services, with a trace ID passed along every call
Deploying	One pipeline, one artifact, everyone ships together	One pipeline per service; teams ship on their own, but API changes need versioning
Running it	One thing to monitor and keep up	Many services, each needing monitoring, alerts, quotas and an on-call owner

Often confused with

Monoliths Serverless architecture Serverless functions (FaaS)API gateways Remote procedure calls Event buses Service discovery & mesh Service layer Monolith, microservices or serverless?

Where it came from1968–2015

Splitting software along team lines is an old idea. In April 1968 Melvin Conway observed that any organisation that designs a system will produce a design that copies its own communication structure, which Fred Brooks later named Conway’s law. In the 2000s large enterprises tried service-oriented architecture (SOA), often built around heavyweight standards and an enterprise service bus. Amazon did its own version earlier and more strictly. By 2001 its monolithic front end couldn’t scale, and it moved to services that each hid their data behind an interface. Steve Yegge, an ex-Amazon engineer, recalled in a 2011 rant a mandate from Jeff Bezos “around 2002, plus or minus a year”: teams must expose data and functionality only through service interfaces over the network, with no direct reads of another team’s data store. In 2006 Werner Vogels said a single Amazon.com page called more than 100 services, and that the teams that build a service also run it.

Netflix followed after a database corruption in August 2008 stopped it from shipping DVDs for three days. Over seven years it rebuilt itself on AWS, from a monolithic app to hundreds of microservices, and called the style “fine-grained SOA”. In May 2011 a workshop of software architects near Venice discussed the term “microservice”, and in May 2012 the group settled on “microservices”. In March 2014 James Lewis and Martin Fowler published the article that defined it: suites of small, independently deployable services, organised around business capabilities, with decentralised data and “smart endpoints and dumb pipes”.

Within a year the backlash began from the same circle. Fowler’s “Microservice Premium” and “MonolithFirst” (2015) warned that the style adds its own complexity and that most systems should start as a monolith; Stefan Tilkov replied on Fowler’s site that starting with a monolith is usually the wrong choice. The debate has not ended, but the costs are now well known: network calls, eventual consistency, tracing and the platform work that every service needs.

Why it’s built this way

Each service owns its data: Amazon found that shared databases tied teams together and blocked scaling. Hiding each data store behind a service interface gave teams isolation, at the cost of no cross-service joins or transactions.
Smart endpoints and dumb pipes: Lewis and Fowler contrasted microservices with SOA’s enterprise service buses, which held routing and business logic. Microservices keep the logic in the services and use simple HTTP or a lightweight message bus between them.
Services sized to teams: Following Conway’s law, services are cut along business capabilities and owned by cross-functional teams. Lewis and Fowler noted that the largest services they saw matched Amazon’s two-pizza team: no more than about a dozen people.
Compensate instead of locking: Distributed transactions are hard and couple services in time, so microservices accept eventual consistency and fix failures with compensating operations. The idea goes back to sagas, proposed by Garcia-Molina and Salem in 1987 for long-lived database transactions.

Timeline

1968
Melvin Conway’s “How Do Committees Invent?” appears in Datamation
1987
Garcia-Molina and Salem propose sagas: transactions undone by compensating steps
2002
Bezos’s service-interface mandate at Amazon, by Steve Yegge’s later account
2008
Netflix starts its seven-year move from a monolith to cloud microservices
2012
Architects meeting near Venice settle on the name “microservices”
2014
Lewis and Fowler publish “Microservices”
2015
Fowler’s “MonolithFirst” and Tilkov’s “Don’t start with a monolith”

Sources9

Improve this page on GitHub