What do Rammstein tickets, Baukindergeld and SV Werder Bremen jerseys have in common? All three were so popular that the respective websites for booking tickets, applying for funding and ordering bibs collapsed within a very short time due to the influx of visitors.

In addition to the anger and disappointment of customers and citizens and the associated loss of reputation for the providers, such failures – caused by excessive traffic – are usually also associated with massive financial losses. In some business models and application scenarios, they would be downright fatal: streaming services such as Netflix and Spotify, IoT networks in smart cities and autonomous vehicles are essentially dependent on the systems on which they are based remain operational under all circumstances, regardless of the amount of data and the required performance.

Recently, Netflix published a post-mortem on a callback problem in the software architecture: In general, the callback came after 15 Milliseconds, but not always. Occasionally it took significantly longer, which led to problems when playing. The Android scheduler framework had a callback of 15 milliseconds requested – however, this only means that the callback is at least 15 May need milliseconds (not at most, but at least, as security expert Felix von Leitner explains in a blog post). The bug might have been avoidable through a different software design. The Reactive Manifesto was created 27 from the cooperation of the companies Netflix, Pivotal and Red Hat. Since then around 27. 000 Developers signed the manifesto, and almost all Reactive publications refer to it. It defines values, non-functional requirements and principles that stand for a reactive architecture (see Fig. 1).

Reactive architectures penetrate ever more deeply into software applications that describe the goals and intentions of this type of architecture this policy paper. However, at first glance it does not seem to provide any new information. It is worth taking a look at the historical development of the architectural styles in order to better understand the concept.

Values, requirements and principles of the Reactive Manifesto (Fig. 1)

(Image: msg Group)

According to the manifesto, the most important value is responsiveness, the fast and reliable response behavior of reactive applications. Elasticity and resilience (both non-functional requirements) should lead to this behavior: Elasticity stands for dynamic scaling depending on the load behavior, and resilience for recognizing failures and correcting them independently.

The load behavior can be different. Sometimes it is access by users from the Internet, sometimes it is the sending of MQTT messages from an IoT device. For example, the elasticity in a microservices architecture can be achieved by adding microservice instances when the load increases and exiting them again when the load decreases. Resilience can be achieved in a microservices architecture by providing multiple microservice instances redundantly so that in the event of a failure another instance can take over the tasks. The system automatically detects the error and restarts the microservice instance so that it can take over the tasks again. Asynchronous communication via messaging should meet these requirements.