Chapter 2. What Is a Reactive Microservice?
One of the key principles in employing a Microservices-based Architecture is Divide and Conquer: the decomposition of the system into discrete and isolated subsystems communicating over well-defined protocols.
Isolation is a prerequisite for resilience and elasticity and requires asynchronous communication boundaries between services to decouple them in:
Allowing distribution and mobility—the ability to move services around
When adopting Microservices, it is also essential to eliminate shared mutable state1 and thereby minimize coordination, contention and coherency cost, as defined in the Universal Scalability Law2 by embracing a Share-Nothing Architecture.
At this point in our journey, it is high time to discuss the most important parts that define a Reactive Microservice.
Isolate All the Things
Without great solitude, no serious work is possible.
Isolation is the most important trait. It is the foundation for many of the high-level benefits in Microservices. But it is also the trait that has the biggest impact on your design and architecture. It will, and should, slice up the whole architecture, and therefore it needs to be considered from day one. It will even impact the way you break up and organize the teams and their responsibilities, as Melvyn Conway discovered and was later turned into Conway’s Law in 1967:
Any organization that designs a system (defined broadly) will produce ...