Reactive Microservices — 1

6 min readJun 15, 2021

This is an 8 part series on reactive microservices. [1 , 2 , 3, 4, 5, 6, 7, 8]

Prologue

The term reactive is ubiquitous. Everything from architecture, to frameworks, to general concept seem to refer to this term. Quite obviously, reactive has assumed many meanings and definitions and can be understood under a certain context. This article aims to dive deep into what being reactive means and to explore on the various contexts where this idea is used. In particular, the article aims to explore the relationship between microservices and reactive and attempt to define what reactive microservices are.

Reactive Systems — Introduction

The operating environment of the enterprises today has complexity as a norm. Cloud Computing, Multiple device types (desktops, mobile devices, wearables, Sensors, Gaming Consoles, Smart Homes), near zero downtime, low latency & petabyte of data processing are few characteristics that have led to a world of services where the experience and expectations of a consumer has changed. In addition, the number of users has increased manifold and these users are always connected.

Organizations are looking for high service availability and also to innovate rapidly.

The traditional N-Tier, CRUD based application design, simply does not address the challenges of this new reality. The architecture patterns, data processing and scaling demands need a new approach of distributed systems to address these challenges.

To cater to such demands on the applications, enterprises have been adopting new architecture thinking, that:

leverages distributed compute resources at scale
is explicit about failures
is inherently asynchronous and non-blocking
removes all contentions from the systems

aiming to leverage resilience and availability from such an approach.

Thus, modern enterprise systems are distributed from ground up. Operating services in a distributed architecture is a challenge and opportunity both. Bringing all the features of this new architecture paradigm into a unified definition, is Reactive Manifesto (https://www.reactivemanifesto.org/). Reactive manifesto underlines the traits of Responsive, Resilience, Elastic, Message Driven in a reactive system.

Reactive — Reacts to what?

Responsive: React to User. System should provide consistent response times and quality of service.

Elastic: Reacts to load. System should stay response under varying workloads

Resilient: Reacts to failures. system should stay response in event of failures

Message-Driven: Reacts to Messages. System should establish asynchronous message passing.

Reactive architecture embraces the inherent nature of distributed systems i.e.

unreliability of network,
latency of data across network,
failures in parts of systems,
eventual consistency of data

This nature of distributed systems was presented as a set of “fallacies” in a 1994 Sun Microsystems paper — Fallacies of Distributed Computing (https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing).

Traditional architectures attempted hide these fallacies with patterns like 2PC XA/Distributed Transactions, WS-Coordination, Other WS-*, CORBA etc. These patterns treated communication across services as if these were local method calls by disguising the network calls as method calls within JVM and making a big assumption that network is always reliable. Reactive Systems are explicit about the network & failures and make them a part of the “flow”. In a distributed system like microservice, there is no guarantee that the service being called is available or that the network would not fail or drop the messages. By being message-driven, such unreliability can be handled with greater flexibility than remote method invocations or distributed transactions.

The end value of reactive systems is Responsiveness, the ability of the application to be always efficiently available. Responsiveness is cornerstone of usability.

Terms & Definitions

Reactive Manifesto

The Reactive Manifesto was penned in 2013 to provide business leaders and technologists with a cohesive approach and common vocabulary to accelerate the evolution toward Reactive systems. https://www.reactivemanifesto.org/.

Reactive Systems

Reactive Systems apply reactive principles at architectural and systems level. Principles mentioned in reactive manifesto are basis of architecture of reactive systems.
Reactive Systems are decoupled asynchronously.
Reactive Systems, which result from adopting reactive architecture can benefit from reactive programming model, although it is not a pre-requisite. But usage of reactive programming alone doesn’t mean Reactive architecture. Reactive systems imply reactive architecture based on reactive principles.
This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur, they meet it with elegance rather than disaster.
Example of Reactive System: Reactive Microservices.

Reactive Architecture

Can mean:

Any architecture that is a realization of reactive principles. It doesn’t assume stack or choice of programming model.
Reactive principles Solution building blocks that enable development. For example, LightBend Akka toolkit and Lagom frameworks are meant for reactive architecture.
Reactive architecture applied across related components, services and applications turn the dials towards Reactive Systems

Reactive Programming

Reactive Programming is based on writing asynchronous non-blocking processing that efficiently uses the threads and CPU cores to reduce the wait/block state of threads, thus removing the CPU contention from threads.
Aims to leverage multi-core CPU architecture instead of relying on the processor clock speed, which has reached a peak (Inverse of Moore’s Law)
Th reactive frameworks provide a way for the programmers to deal with a thread model that eliminates the need for thread waits. Constructs like Promise or a Future or Stream are used to handle the response that is available “sometime in future”.
The major specification on reactive programming models is Reactive Streams. This specification provides contracts to enable message stream processing in async non-blocking fashion.
Reactive programming style is not new and has been around in various forms like event-listeners in swing and browser JavaScript DOM libraries
Reactor, RxJava / RxScala framework, Akka are examples of reactive programming tools.
usage of reactive programming model doesn’t automatically mean a reactive system or a reactive architecture.

Reactive microservices

Developing microservices based applications on reactive principles and programming model results in reactive microservices. Reactive Architecture and Microservices had evolved independently. Reactive principles can be applied to practically any kind of architecture and microservices can be developed in traditional “sync-REST” style as well. But because both ideas are rooted in handling distributed services, the notions of consistency, availability, latency, time, scalability & time are common concerns to solve. Reactive microservices enables maximum leverage of inherent distributed nature. Reactive microservices is one application of reactive architecture.

The message-driven aspect of the reactive manifesto is the pervasive driver in reactive microservices and fits right into the evolution of distributed microservices (from a monolith or to alleviate the distributed monolith problem).

It is possible that microservices are developed without any consideration for either reactive manifesto or reactive programming, but the maturity for such a microservices would be low.