Concerns of Reactive Systems

Let's talk about why we build reactive systems, as software engineers/developers.

As professionals, we have to balance two concerns in relation to each other. On one hand, the demand for our work is driven largely by business needs. On the other hand, we still have to keep the technology in mind. The careers of programmers shouldn't be defined strictly by corporate needs. Technology does more than check boxes for project requirements.

Models like reactive systems architecture help bridge the gap. Reactive system architecture concerns itself with customer requirements first and foremost, with motivation coming directly from what we expect from, and how interact with, technology.

Today's consumers expect high levels of resilience. Today's consumers expect responsiveness. To satisfy modern requirements, and those systems which require reactiveness, we use reactive programming methodologies. The unifying principles are the reactive principles.

Reactive Principles:

Here we have a commonly used model of reactive principles. Notice that all arrows point to responsiveness. Once all other requirements are met, our last concern is responsiveness. We also have other requirements like elasticity (ability to properly utilize all necessary available resources) and resiliency (ability to adjust under unexpected circumstances). And finally, we have an underlying message-driven architecture, which enables us to move forward in satisfying these requirements.

Conclusion:

Satisfying the message-driven constraint doesn't mean you've built a proper reactive system, but it is important. In fact, all four requirements should be satisfied, but all four have limitation. For example, it's well known that strong consistency and scalability are often in competition with each other. It's the job of an engineer to properly assess technologies and build architecture that satisfies business and consumer requirements.