Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

Reactive Systems

“Reactive system” names a set of architectural properties rather than a library or a framework. The Reactive Manifesto, published in 2014, states four:

  • Responsive — the system responds in a timely manner whenever it is at all possible. Response times are bounded and known, which is what makes problems detectable and error handling meaningful.
  • Resilient — the system stays responsive in the face of failure. Failures are contained within a component so they cannot take the rest of the system with them, and recovery is delegated to another component rather than attempted by the failed one.
  • Elastic — the system stays responsive under varying workload. It reacts to changes in input rate by acquiring or releasing resources, which means no contention points and no central bottleneck.
  • Message driven — components communicate by asynchronous message passing. That boundary is what makes the other three achievable: it isolates components, allows load management and back-pressure, and turns failures into messages that a supervising component can act on.

The order matters. Responsiveness is the goal; resilience and elasticity are how it survives failure and load; message passing is the mechanism that makes both possible. A system that adopts an asynchronous library without containing failures or bounding response times has adopted the mechanism and none of the properties.

The practical consequence for service design is back-pressure. If a consumer cannot keep up, it must be able to signal that upstream, so the producer slows down rather than letting queues grow without bound until the system fails in a way nobody has designed for.

Further reading

Section titled “Further reading”