Reactive Systems Explained

Foreword

Dear reader,

In an ever-changing software landscape, user expectations grow ever more demanding. Developers need to be able to produce business value at a sustainable, rapid pace and for a user base whose size we do not necessarily know.

I started my own reactive journey back in 2009, when I asked myself whether developer productivity and software scalability were fundamentally incompatible. I realized that the most accurate system in the world would be pointless if it never provides value at the moment it is needed. That requires responsiveness. To address the challenge of responsiveness, we need to consider the evil twins that always play tricks on us: load and failure. What does the distribution of response times look like under varying load and failure conditions?

To handle failure conditions, we need replication and redundancy to ensure that functionality is still available; to cope with varying loads, we need elasticity to ensure that processing capacity can be adjusted dynamically according to demand. We need to break free of the single-machine assumption. We also need to consider infrastructural failures such as power or network failures. Different machines being spread out geographically also gives us the opportunity to serve consumers from the closest servers.

Elasticity also implies distribution. To share the increased processing burden, we need to be able to add (and remove) machines and redirect traffic dynamically. This also has a secondary benefit in as ...