Stateless microservices are very beneficial. To put it more clearly, microservices should not save any state in their logic layer. States held in a database or on the client side are acceptable. When using a stateless approach, the failure of an individual instance does not have a big impact. The instance can just be replaced by a new instance. In addition, the load can be distributed between multiple instances without having to take into consideration which instance processed the previous calls of the user. Finally, the deployment of a new version is easier since the old version can just be stopped and replaced without having to migrate its state.


Implementing microservices with Reactive[1] technologies can be particularly useful. These approaches are comparable to Erlang (see section 14.7): Applications consist of actors. In Erlang they are called processes. Work in each actor is sequential; however, different actors can work in parallel on different messages. This enables the parallel processing of tasks. Actors can send messages to other actors that end up in the mailboxes of these actors. I/O operations are not blocking in Reactive applications: A request for data is sent out. When the data is there, the actor is called and can process the data. In the meantime, the actors can work on other requests.

Essential properties according to the Reactive Manifesto:

  • • Responsive: The system should react to requests as fast as possible. This has among others advantages for fail fast and therefore for stability (see section 9.5). Once the mailbox is filled to a certain predetermined degree, the actor can, for instance, reject or accept additional messages. This results in the sender being slowed down and the system does not get overloaded. Other requests can still be processed. The aim of being responsive is also helped if blocking I/O operations are not used.
  • • Resilience and its relationship with Reactive applications has already been discussed in section 9.5.
  • • Elastic means that new systems can be started at run times that share the load. To achieve this, the system has to be scalable, and it has to be possible to change the system at run time in such a way that the load can be distributed to the different nodes.
  • • Message Driven means that the individual components communicate with each other via messages. As described in section 8.4, this communication fits well with microservices. Reactive applications also use very similar approaches within the application itself.

Reactive systems are particularly easy to implement using microservices and the concepts from Reactive fit neatly with microservices’ concepts. However, similarly good results can also be achieved by the use of more traditional technologies.

Some examples of technologies from the Reactive arena are:

  • • The programming language Scala[2] with the Reactive framework Akka[3] and the web framework Play[4] [5] is based on it. These frameworks can also be used with Java.
  • • There are Reactive extensions11 for practically all popular programming languages. Among them are RxJava[6] for Java or RxJS[7] for JavaScript.
  • • Similar approaches are also supported by Vert.x[8] (see also section 14.6). Even though this framework is based on the JVM, it supports many different programming languages like Java, Groovy, Scala, JavaScript, Clojure, Ruby, and Python.

  • [1]
  • [2]
  • [3]
  • [4]
  • [5]
  • [6]
  • [7]
  • [8]
< Prev   CONTENTS   Source   Next >