” It’s becoming obvious that the old, linear, three-tier architecture model is obsolete. ”
(A Gartner Summit track description)

” It is becoming increasingly clear that the old three-tier architecture model is obsolete. ”

Margo Consultants participated in  Devoxx France 2018 , the conference for Passionate Developers, organized from April 18 to 20, 2018 in Paris. Discover below a synthesis on reactive systems illustrated by a concrete use case.

What is a reactive system?

Reactive systems are an architectural style that allows multiple individual applications to blend into one unit, reacting to their environment, while staying aware of each other.

The first formalization of this term came about with the creation of the ” Reactive Manifesto ” in 2013 by Jonas Boner who, by bringing together some of the brightest minds in the distributed systems industry, wanted to clarify the confusion around reactivity ( which has become a “buzz-word”) and build a solid foundation for a viable development style. Thus “Reactive Manifesto” describes a set of principles necessary to build systems capable of responding to queries very quickly and this even in case of failure or overload.

Why build reactive systems?

Suppose we want to build a system that:

• Reduces latency
• Manages breakdowns and relies
• Manage load peaks
• Is able to send, receive, and forward messages in an unreliable network

These responses actually convey the basic characteristics as defined in the “Reactive Manifesto”.

How to build a reactive system?

The reactive systems adopt the “Message driven” approach. All components interact through messages sent and received asynchronously. This messaging communication creates a temporal boundary between the components, making decoupling possible over time (allowing competition) and space (allowing for distribution and mobility). This decoupling is a requirement for complete isolation between components and is the basis of resilience (the ability to handle failures and recover) and elasticity (the ability to “scaler” horizontally).

Elasticity comes from decoupling in space. Producers send the data to a virtual address and consumers consume it from another. Thus, the messages sent will be processed by a set of consumers through a load balancing strategy. And when the system will face a peak load, it will just launch new instances and get rid of it later.

Resilience is provided by the ability to handle non-blocking failures and the ability to replicate components. First, message interactions allow components to handle failure locally. Because of the asynchronous aspect, the components do not actively wait for the responses, so a failure in one component will not affect the other components. Replication is also a key ability to manage resiliency. When a node processing message fails, the message may be processed by another node registered at the same address.

With these two features, the system becomes responsive. It can adapt to higher or lower loads and continue to meet the demands in case of heavy loads or failures. This set of principles is essential when creating highly distributed microservice systems and when interacting with services outside the control of the caller. It is necessary to run multiple instances of each service to balance load and manage outages without interrupting availability.

A responsive system is for whom?

This architecture model is very relevant for applications interacting in real time with users. This includes :

• Shared documents (Google docs)
• Social networks (Streaming)
• Financial analysis (Market flow)
• More efficient management of complex algorithms (Graph Management, Semantic Web …)

A concrete use case: LinkedIn

LinkedIn offers an instant messaging system, which describes in real time the status of 500 million members. For this they used Play Framework and Akka Actor Model , tools to set up a responsive system.

Thus, in order to distribute a member’s presence status changes to a potentially huge number of relationships, they have implemented a Message Driven system that allows data to be broadcast from the server to the server. Mobile or Web clients, via a persistent connection.

When Alice member opens LinkedIn on their mobile device or browser, a permanent connection is established with the real-time platform. The existence of this connection is a clear indication that Alice is currently online. Eventually Alice may be interested to see if Bob is currently online. For this, the platform allows Alice to subscribe to a topic “Status of Bob” (consumed from a virtual address, Decoupling in space) to track Bob’s presence status. Once Bob opens his app, the platform will know that Bob is online and will be able to post this event on Bob’s status topic. Subsequently the presence platform will send this event in real time to all subscribers to this topic, including Alice. So, Alice would see Bob’s presence indicator go green.

However, there is another problem that needs to be addressed, the network! (The network on your mobile is not the most reliable – Resilience).

Alice and Bob are on their mobiles, and the network on the phones is unreliable. As it stands, the network’s micro-cuts will flood the system with “false” status changes and cause a bad user experience for Alice and Bob, whose status, as well as that of their relationships, will not stop switcher “between online / offline.

To remedy this, LinkedIn has implemented a system of heartbeat.

Once the persistent connection is established, the real-time platform begins to emit heartbeats with the member ID every d seconds. This duration serves as a guard against fluctuations in the presence status of a member. As long as a heartbeat is received every d second, the presence platform will consider that the member is still online. Thus, if a member abandons his connection, due to a network problem, and reconnects within seconds, he will be considered online. This would not have been possible without the decoupling over time.

At each “heartbeat” reception, the “heartbeat process” checks to see if there is an unexpired entry for that ID in the “cache cache” cache.

If no entry exists or the previous entries have expired, it is concluded that the member has just logged in.

• An online presence status event for this member is published on the real-time platform to distribute this event to the member’s connections.
• An entry is added to the cache with an expiration time slightly greater than d seconds (d + ε) to keep the record alive until the next heartbeat.

If an unexpired entry exists

• The member is already online, so just update the “lastHeartbeatTS” for that member ID.

Sources:

Bibliography

• Why Reactive – Konrad Malawski
• Building Reactive Microservices in Java – Clement Escoffier

Webography:

• A brief overview of reactive systems
• Reactive Manifesto
• Reactive Systems – Overview
• The reactive revolution
• Now You See Me, Now You Do not: LinkedIn’s Real-Time Presence Platform

Conference:

Session University ”  Introduction to Data Streaming “, moderated by  Clement Escoffier and  Galder Zamarreño  on Wednesday, April 18th.