Functional Programming and Reactive Architecture (Part 2)

DZone 's Guide to

Functional Programming and Reactive Architecture (Part 2)

See why functional programming fits so well with reactive architecture by examining the crucial components of reactive systems.

· Java Zone ·
Free Resource

As engineers, we want to build systems that are valuable for consumers; a reactive system strives to provide a correct answer in a timely manner to its users whether they are humans or other systems. For this reason, a fundamental quality of such systems is responsiveness.


A responsive system establishes the upper bounds for acceptable latency. Latency is the time that passes between a request and the response. Predictable latency and correct answers provide confidence in the system, help error handling, and enforce further system usage. To design a responsive system, we work with three main aspects: resiliency, concurrency, and elasticity.


It is really frustrating when a system gets stuck in an inconsistent state caused by a failure; that system lacks a stable design with the direct consequence of not being responsive. We have to design a system that could keep working through failures by adding redundancy, isolating the components to avoid cascading effects, and (when everything else fails) restarting part of it without affecting the whole. This would free the user of the components from the handling of failures. To achieve this level of separation, we could design concurrent systems.


Reactive systems achieve concurrency and isolation through asynchronous message passing. This enforces decoupling and modularization, simplifying logging and monitoring. Failures themselves could be handled through delegation using messaging. Message passing promotes a better and clearer separation of concerns where a message would specify what to do and a message handler would take care of how to do it. All of these properties enable elasticity using queues to mitigate spikes in system load.


An elastic system provides a consistent latency by dynamically allocating resources as the need arises and optimizing their usage when the system faces less pressure. Queues and independent components enable horizontal scalability providing a more consistent and manageable latency reducing bottlenecks and allowing replication.

The Actor Model

The actor model started as an attempt at defining an abstraction to describe efficiently and expressively the problem of concurrently cooperative execution of desired actions when it became evident that the future of computing would be distributed and parallel. Actors are units of computations that communicate asynchronously through messages; their very nature is highly concurrent, enabling parallel problem-solving.

The Big Picture

The reactive model requires good modularization so that the actors responsible for handling their messages can execute their domain behavior effectively and concurrently. This is easier to achieve when there is no shared mutable state between them.

This is the reason why functional programming is a perfect fit; referential transparency and modularization are encouraged from the very beginning and at every level. You're using pure functions and immutable data structures that decouple side effects from pure logic, enabling scalability, concurrency, and composability.

functional programming, java, reactive architecture

Published at DZone with permission of Alessandro Di Gioia , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}