What are the core principles of Reactive Systems?
Updated Feb 20, 2026
Short answer
The Reactive Manifesto defines four principles: responsive, resilient, elastic, and message-driven. Responsiveness is the goal — consistent, predictable reply times. Resilience and elasticity are how responsiveness survives failure and load. Message-driven asynchronous communication is the foundation that makes the other three achievable.
Deep explanation
The four principles form a dependency chain rather than a flat list, which is the detail interviewers probe.
Message-driven is the foundation. Components communicate by asynchronous, non-blocking message passing. The sender does not wait for the receiver, which decouples them in time (the receiver need not be available now), in space (it may live anywhere), and in failure (its crash does not propagate up a call stack).
Resilience is built on that foundation. Because components are isolated by messages, failure is contained. Reactive designs treat failure as expected: supervision hierarchies restart failed components, bulkheads stop one subsystem exhausting shared resources, and circuit breakers stop hammering a service that is already struggling. Crucially, recovery is handled outside the failed component — a component cannot reliably repair itself.
Elasticity also depends on the foundation. Location transparency means adding a second consumer requires no change to producers. Elasticity is bidirectional — scaling down under light load matters as much for cost as scaling up matters for capacity.
Responsiveness is the outcome: bounded, predictable latency, including in the failure case. A fast error response beats a request that hangs for thirty seconds.
The chain is worth stating explicitly: message-driven enables resilience and elasticity, which together produce responsiveness. Teams that adopt the vocabulary but keep blocking calls get none of it.
Real-world example
A video platform's transcoding tier illustrates all four.
Uploads publish a VideoUploaded message rather than transcoding inline (message-driven) — the user's upload returns in seconds while transcoding runs for minutes.
A worker that crashes mid-transcode has its message returned to the queue and retried elsewhere; a supervisor restarts the worker; a poisonous message that repeatedly fails is diverted to a dead-letter queue rather than blocking the line (resilient).
Queue depth drives autoscaling: a backlog of ten thousand videos scales workers from 5 to 200, and back down overnight (elastic).
Through all of it the upload endpoint replies in the same time, because it does no transcoding work (responsive).
Common mistakes
- - Reciting the four words without grasping that message-driven is the mechanism the other three rest on.
- - Confusing 'message-driven' with 'event-driven' — a message has a designated recipient, whereas an event is broadcast to whoever cares. Reactive systems use both, for different purposes.
- - Treating elasticity as scale-up only, missing the cost consequences of never scaling down.
- - Handling failure inside the failing component
- genuine resilience requires an external supervisor, since a corrupted component cannot be trusted to repair itself.
- - Assuming responsiveness means 'fast'. It means *predictable* — a bounded, consistent response time, including a prompt failure response.
- - Adopting reactive libraries while retaining blocking I/O, which produces the complexity of async code with none of the isolation benefits.
Follow-up questions
- Why is message-driven considered the foundation of the other three?
- What is the bulkhead pattern?
- How does a circuit breaker support resilience?
- Is responsiveness the same as low latency?