10 Microservices

 

This chapter covers

  • The basics of microservices
  • The backend-for-frontend pattern
  • Using asyncio to handle microservice communication
  • Using asyncio to handle failures and retries

Many web applications are structured as monoliths. A monolith generally refers to a medium-to-large-sized application containing multiple modules that are independently deployed and managed as one unit. While there is nothing inherently wrong with this model (monoliths are perfectly fine, and even preferable, for most web applications, as they are generally simpler), it does have its drawbacks.

As an example, if you make a small change to a monolithic application, you need to deploy the entire application, even parts that may be unaffected by your change. For instance, a monolithic e-commerce application may have order management and product listing endpoints in one application, meaning a tweak to a product endpoint would require a redeploy of order management code. A microservice architecture can help with such pain points. We could create separate services for orders and products, then a change in one service wouldn’t affect the other.

10.1 Why microservices?

10.1.1 Complexity of code

10.1.2 Scalability

10.1.3 Team and stack independence

10.1.4 How can asyncio help?

10.2 Introducing the backend-for-frontend pattern

10.3 Implementing the product listing API

10.3.1 User favorite service

10.3.2 Implementing the base services

10.3.3 Implementing the backend-for-frontend service

10.3.4 Retrying failed requests

10.3.5 The circuit breaker pattern

Summary