A microservices architecture implies the presence of multiple parts in an application. In the past, most applications were monoliths, with all of the parts contained in a single code base. The microservices approach gives us the opportunity to split a code base between multiple teams and developers, to have an individual life cycle for every microservice, and for parts to interact with a common protocol.

Does this mean that your application will be free from all of the flaws of a monolithic application? No. You can write microservices that are so closely related to each other that you can't even properly update them.

How is this possible? Imagine that you have a microservice that has to wait for the response of another microservice to send a response to a client. The other microservice, in turn, also has to wait for another microservice, and so on. If you closely link the microservices of an application, you will find the same drawbacks that you have with monoliths.

You have to write microservices as independent applications that can be reused for multiple projects, not only yours. How can you achieve that? Develop a reactive microservice. Let's look at what that is.