Microservice Design Principles

This training material explains the concepts of microservice architecture through an analogy of factories and warehouses. The main topics are as follows.

• Comparing monolithic and microservice architectures
• The problem with chatty microservices
• Sound microservice design principles
• The dangers of database-centric design
• How to design process-centric microservices

Along the way, it makes the common mistakes in microservice design, and their solutions, easy to understand.

Let's start with monolithic architecture. It is like one enormous factory. This factory gathers in one place all the materials and tools needed to make every kind of appliance: TVs, refrigerators, washing machines, and more. Having everything under one roof may look convenient, but over time a number of problems surface.

Microservice architecture is like splitting that giant factory into several small, specialized factories. Each factory focuses on a specific part or process. For example,

1. Parts factory: a factory that makes display panels for TVs
2. Assembly factory: a factory that receives finished parts and assembles them into the final product

Divided this way, each factory can concentrate on its own area of expertise, and it becomes easier to scale or upgrade as needed.

But if microservices are designed poorly, you can fall into a problem called "chatty microservices." This is like,

1. the assembly factory sending small requests to the parts factory every time it needs something
2. the assembly factory reaching directly into the parts factory's raw-materials warehouse

These situations create unnecessary dependencies between factories and reduce the efficiency of the whole system.

• Data locality: Each service (factory) should keep the data (materials) it needs for its work close at hand.
• Exchange semi-finished goods: Wherever possible, factories should exchange outputs at the level of semi-finished products.
• Clear separation of responsibilities: Each service should focus on its own domain and not interfere with the internal work of other services.

One of the most common mistakes in designing microservices is dividing services along the structure of the database. That is like dividing factories by the type of raw material they use. This approach can cause the following problems.

• Increased data dependencies
• Fragmented business processes
• Excessive communication between services

Instead, services should be designed around the flow of the business process, the "value stream." This is like dividing factories according to the stages a product goes through as it is made.

1. Group the data and work needed at each stage (value step).
2. Define bounded contexts on that basis and divide services accordingly.
3. Secure data locality within each service.

Microservice architecture is a powerful tool, but it only delivers its benefits when designed correctly. By avoiding anti-patterns such as chatty microservices and designing services around the flow of the business process, you can build an efficient and scalable system.