The Reactive Manifesto names responsive, resilient, elastic and message-driven - how do those four properties depend on one another?

## What the four properties claim The Reactive Manifesto names four properties a system may claim: **responsive**, **resilient**, **elastic** and **message-driven**. They are usually recited as a flat list of adjectives, and that recital is exactly what an interviewer is listening for, because it is what a candidate says when none of the four has ever been measured. The four are layered: one is the goal, two are the means by which the goal survives contact with real load and real failure, and one is the foundation the two means are built on. - **Responsive** - a named request answers within a bound that holds under the load and the failures the system claims to handle. It is the only property of the four stated in terms of somebody outside the system. - **Resilient** - a failure is contained inside one component, and recovery is delegated to something outside the failed part, so the rest keeps answering inside the bound. - **Elastic** - the resources committed track load in both directions, and the bound holds across the range, provided nothing shared and serialized sits in the path where replication cannot relieve it. - **Message-driven** - components communicate by asynchronous messages across a boundary, instead of one component holding a resource open while another works. ## The dependency order, with the evidence for each | Property | Layer | The claim | Evidence that settles it | |---|---|---|---| | Responsive | goal | a stated percentile of a named request stays under a stated bound at a stated arrival rate | a load curve: that percentile plotted against arrival rate, including where the bound breaks | | Resilient | means | one component failing does not move the bound for requests that do not depend on it | an injected failure under load, measured against a control path that never touches it | | Elastic | means | the bound holds across a load range, and resources are released again when load falls | a ramp up and back down with the percentile measured through both halves | | Message-driven | foundation | no component is pinned to another's progress; results and failures arrive as messages | a boundary where a slow recipient changes what the sender does, not how long it waits | Read the table downwards and the order is visible. Only the first row mentions a person. The next two rows are conditions under which the first row stays true - one for failure, one for load. The last row is a structural precondition for the middle two. ## Why two of the four are means and not virtues A response-time bound is easy to satisfy in a benchmark and hard to satisfy in the world, and the two ways the world breaks it are failure and load. 1. **Without resilience**, the bound holds only while nothing fails, which makes it a claim about luck. Containment is what converts a component failure from a system-wide latency event into a local one. 2. **Without elasticity**, the bound holds only at the one load it was measured at. A system sized for the average of a spiky workload misses its bound exactly when the most people are watching. 3. **With both**, the bound becomes a statement with conditions attached, which is the only kind of statement that can be checked. Neither means is wanted for itself. Nobody experiences containment; they experience a page that still answered while something behind it was broken. ## Why message passing sits underneath Asynchronous message passing between components is not a fourth benefit alongside the others. It is what makes the two means implementable: - A boundary that receives messages can decide when it takes the next one, so the amount of work admitted is bounded at the boundary rather than pushed through on arrival. - A recipient addressed as a component rather than held by a caller's stack can be replicated, replaced or moved while callers keep sending - the precondition for elasticity and for recovery. - A failure can travel as a message to something that is not itself failing, instead of unwinding the caller's call stack and becoming the caller's failure - the precondition for containment. A system claiming resilience or elasticity while every component waits on the next one synchronously is usually claiming a wish rather than a property. ## Where the order gets stated backwards 1. **Message-driven read as the goal.** Teams announce asynchronous internals as the achievement. It is the foundation, and on its own it is invisible to users. 2. **Responsiveness read as raw speed.** Measured on an idle system it means nothing; the property is about a bound under stated conditions. 3. **Elasticity read as growth only.** Releasing resources afterwards without a latency regression is the harder half, and it is what shows there is no hidden contention point that only tolerates growth. ## What this sounds like in an interview The strong answer states the layering in one sentence, then attaches a measurement to each property. The weak answer lists four adjectives in the order it memorised them. The follow-up an interviewer usually reaches for is "which of the four would you check first in a service that claims all of them?" - and the answer is the goal, because the other three are only interesting insofar as it holds.