Medium Microservice Architecture Practice

Please clap and share if you like this article.

I used Medium (this platform) as an example throughout the article.

Many startup companies use the technology stack started as a monolithic Node.js application and built several satellite communication services, but have not yet systematically adopted a microservice architecture. As the system became more complex, the team have to produce a better solution to minimize the impact on the system. The goal of microservice architecture is to help engineer teams deliver products faster, safer, and with higher quality.

In the microservice architecture, multiple loosely coupled services work together. Each service focuses on one purpose and is highly cohesive with related behaviors and data. The definition includes 3 design principles:

1. Single-purpose — each service should focus on one purpose and do it well
2. Loosely coupled services do not have much contact with each other. Changing one service should not require changing other services. Communication between services should only be done through public service interfaces.
3. High cohesion — each service encapsulates all related behaviors and data together. If we need to build new features, all changes are limited to one service.

This is the only way to fully utilize the potential of the microservice architecture. The lack of either will become an anti-pattern. Without a single purpose, each microservice will eventually do too many things and grow into multiple “monolithic” services. We will not get all the benefits from the microservice architecture but also pay for the operating costs. Without loose coupling, changes to one service will affect other services, so we cannot release changes quickly and safely, which is the core advantage of microservice architecture. More importantly, the problems caused by tight coupling can be catastrophic, such as data inconsistency or even data loss. Without high cohesion, we will end up with a distributed monolithic system, a set of chaotic services, which must be changed and deployed at the same time to build a single function. Due to the complexity and cost of multiple service coordination (sometimes across multiple teams), a distributed monolithic system is usually much worse…