Microservices vs Monolithic


Why not Monolithic anymore?

When the codebase grows so big you cannot control. It’s time to find the new way to manage the codebase.

How to reduce the complexity of a giant codebase(which we call monolithic)?

Think about the time when you were dealing with code only. When it grows to big, you split it to smaller modules. You create classes that focus on a main small task. You follow cohesive and loose coupling principles.

The similar thing can be applied to a codebase, in which you split not only the code but also its network, external services and sometime database. It is like creating a completely new project which responsible for a main small task. We name it Microservices.

What are actually Microservices?

Microservices are small and autonomous services that work together.

Small here literally means a small service and codebase that serve specific functionality inside the business. Smaller is better but too small will increase the complexity of management.

Autonomous defines the service should become a separate entity. It is isolated and deployed on its own operating system process. The goal is we change a service without affect other things.

Key benefits

Now you can merely grasp the idea of Microservices. How we apply the concepts of distributed systems and service-oriented architecture will determine the advantage of Microservices. Let’s see how it can help to leverage your system.

Technology Heterogeneity

Because of the independency of services, we are free to pick different technology stack for them.

Moreover, this methodology will also encourage experimental . Trying a new stack in a small service can illustrate clearly the positive and negative impacts so that we can make better adoption for new technology.


It is apparent that in monolith system, it’s very common for an entire system down when a fault happens. In Microservices architecture, we don’t need to worry about that because even if a service fails, the other parts can still work as they are totally independent with that service.


Because each component is independent. Its easier to scale a piece when not touching other parts.


Each microservice is small enough to be handled by a team. Because they can handle the whole development process including picking the tech stack and deployment. The less dependency with other team, the faster the development can become. For example, you don’t need to wait infrastructure team to add more resources before you implement on them.


There are some tradeoffs when we decide to go with Microservices. The communication over network can affect the performance. The test will be harder to handle all microservices together. When we need to do some transaction that requires interaction over network, we reduce the autonomy. We should apply the concept of distribution system like eventual consistent or event-driven architecture to handle the complexity.

However, that’s the tradeoffs you should choose. Based on your system, you should pick what you think suitable the most for you considering the drawback.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.