What Are Microservices Really All About? (And When Not To Use It)

Microservices architecture enables large  teams to build scalable applications that are composed of many loosely coupled services. What does a typical microservices  architecture look like? And when should we use it?

Let’s take a look. Microservices are loosely coupled. Each service handles a dedicated function  inside a large-scale application.

For example, shopping cart, billing, user profile, push notifications can all  be individual microservices. These functional areas are  sometimes called domains. Microservices communicate with each other via  well-defined interfaces with small surface areas.

The small surface areas limit the  blast radius of failures and defects. It makes each service easier to reason about  in the context of the entire application. Microservices talk to one another over a  combination of remote procedure calls (RPC), event streaming, or message brokers.

RPC like gRPC provides faster  response, but the blast radius, or the impact to other microservices, would  be larger when the service was to go down. Event streaming provides better isolation  between services but they take longer to process. Microservices can be independently deployed.

Since each service is small, easier to  reason about, and has a smaller blast radius, this gives the operators peace of  mind and confidence to deploy often. Microservices provide more flexibility to scale  up individual microservices independently. The operational flexibility is invaluable.

Well-architected microservices  practice strong information hiding. This often means breaking up a monolithic  database into its logical components and keeping each logical component well hidden  inside its corresponding microservice. By logical component, it could mean  a separate schema within a database cluster or an entirely separate physical database.

This is an implementation detail. However, one big drawback of microservices  is the breaking up of the database. By breaking up a database into separate  logical units, the database can no longer maintain foreign key relationships and enforce  referential integrity between these units.

The burden of maintaining data integrity  is now moved into the application layer. Let’s take a look at other critical  components required for a successful implementation of microservices architecture. A key component is an API gateway.

API gateway handles incoming requests and  routes them to the relevant microservices. The API gateway relies on an identity provider  service to handle the authentication and put authorization of each request  coming through the API gateway. To locate the service to  route an incoming request to, the API gateway consults a service  registry and discovery service.

Microservices register with this  service registry and discover the location of other microservices  through the discovery service. There are other useful components  in a microservices architecture like monitoring and alerting, DevOps toolings for  deployment, and troubleshooting, for example. Let’s wrap up by discussing when  to use microservices architecture.

Microservices cost money to build and operate. It really only makes sense for large teams. For large teams, it enables team independence.

Each domain, or function, can be  independently maintained by a dedicated team. In a well-designed microservices architecture, these independent teams can move fast, and the  blast radius of failures is well-contained. Each service could be independently  designed, deployed, and scaled.

However, the overhead of a sound implementation is so large that it is usually not  a good fit for small startups. One advice for startups is to design each function  in the application with a well-defined interface. One day if the business and team  are growing fast that microservices architecture starts to make sense, it  would be more manageable to migrate.

If you would like to learn more about system  design, check out our books and weekly newsletter. Please subscribe if you learned something new. Thank you so much, and we’ll see you next time.