Microservices: Small Services, Each With Its Own Database

Microservices divide an application into small services, each built and deployed separately, each owning its own data, and each talking to the others over the network. Every service is usually owned by one team, which can change and release it without waiting for anyone else.

What it makes easy. Each team deploys its service on its own schedule. Each service scales on its own: the catalogue can run twenty copies while accounts runs two. A failure can stay inside one service if the others are built to cope. And each service can use the storage that suits it.

What it makes hard. Calls that were function calls are now network calls, which are slower and can fail or time out. A change across two services needs two coordinated releases. Data that was one transaction now spans databases, so keeping it consistent needs patterns such as a saga, a series of steps each with an undo. And there is far more to run: deploys, monitoring and tracing a request through many services.

The rule that makes it work. Each service owns its data, and others reach it only through the service's interface. That is what makes deploys independent. A service that reads another's tables directly has to change whenever those tables change.

A company known to use it. Netflix spent seven years moving from one large application in its own data centres to hundreds of services on AWS, and described finishing the move in 2016 (Yury Izrailevsky, "Completing the Netflix Cloud Migration", Netflix, 2016).

So adopt microservices when team independence is worth the price of a network between every part, and give each service its own data or it gains little.