With all the buzz around distributed computing, what does a user expect from such a system in the event of the failure of one or more components? Does a single failure result in a catastrophic domino effect, resulting in the failure of the entire system? Or does the system bounce back from such an event with grace and within expected timelines? The end user shouldn't be affected at all in such scenarios, or the system should at least minimize the impact to an extent, ensuring that user experience is not affected.
Reactive microservices take the concept of microservices to the next level. As the number of microservices grows, so does the need for communication between them. It won't be very long before the task of tracking a list of a dozen other services, orchestrating a cascading transaction between them, or just generating a notification across a set of services, becomes a challenge. In the scope of this chapter, the concept of cascading is more important than the transaction itself. Instead of the transaction, it could very well be just the need to notify some external system based on some filtering criteria.
The challenge arises as an enterprise-level microservice-based system would always extend far beyond a handful of microservices. The sheer size and complexity of this cannot be pictured fully here in a chapter. In such a scenario, the need to track a set of microservices and communicate with them can quickly become nightmarish.
What if we could take away the responsibility of communicating an event to other microservices from individual microservices? The other aspect of this could very well be freedom for the services in the ecosystem from being tracked. To do this, you will have to keep track of their whereabouts. Just add authentication to this and you could very easily be tangled in a mess you never signed up for.
The solution lies in a design change, where the responsibility of tracking microservices for an event or communicating an event to others is taken away from individual microservices.
While transitioning from a monolithic application to a microservice-style architecture, we learned that they are isolated. Using seam identification, we isolated modules into independent sets of services that own their data and don't allow other microservices/processes to access them directly. We achieved autonomy by catering to a single business functionality and taking care of aspects such as its data and encapsulated business functionality. Asynchronous was another characteristic that we achieved for our microservices in order to make non-blocking calls to them.