Microservices

How to split one application into small services that separate teams can build, deploy and run on their own: where to draw the lines, how the services share data and call each other, and what the split costs.

Overview

A microservice is a small service that does one job for the business, runs in its own process, owns its own data, and talks to other services only over the network, through an API such as HTTP or gRPC, or by sending messages. A microservice architecture builds one application from many such services, instead of one large program, which is called a monolith.

The main reason to split is people, not performance. When dozens of engineers change one code base, every release waits until everyone's work is ready, and a bug in one corner can block them all. If each team owns a service that it can deploy on its own, the teams stop waiting for each other. James Lewis and Martin Fowler, who described the style in 2014, made independent deployment part of its definition.

The price is that every call between services becomes a network call that can be slow or fail, the data is spread across many databases, and there are many more things to deploy, watch and secure. Netflix spent seven years, from 2008 to early 2016, moving from its own data center to the cloud and rebuilt itself as hundreds of microservices on the way. In 2018 Segment went the other way and merged more than 140 services back into one.

This chapter covers where to draw service boundaries, how services share data and call each other, how to stop one failure from spreading, how to see what a request did, and how to move off a monolith one piece at a time.

What you will be able to do

  • Explain why teams split an application into services, and what they pay for it.
  • Draw service boundaries around bounded contexts, and spot a boundary that is wrong.
  • Keep each service's data private, and still answer queries and run business actions that span services.
  • Choose between a synchronous call and an event, and stop one slow service from taking down the rest.
  • Trace one request across many services, and plan a migration with the strangler fig pattern.

Key concepts

  • Independent deploys
  • Bounded contexts
  • Database per service
  • Sagas and the outbox
  • Sync and async calls
  • Timeouts, retries, circuit breakers
  • Distributed tracing
  • Service mesh
  • Strangler fig migration
  • Distributed monolith

Interview questions

  • What is a microservice, and why would a company split its application into them?
  • How would you choose the service boundaries for an online store?
  • Why should each service own its database, and how do you then answer a query that needs data from two services?
  • Placing an order touches orders, inventory and payments. How do you keep the data consistent?
  • When should one service call another synchronously, and when should it send an event?
  • One slow downstream service is making the whole system slow. What do you do?
  • A checkout request takes 3 seconds and passes through ten services. How do you find out why?
  • What is a service mesh, and when is it worth it?
  • How would you move a large monolith to microservices?
  • When would you advise a team not to use microservices?

Sign up free to read the full topic

More System Design topics

Start free on Cariara · Coding problems · System design studio