Similar with asynchronus programming[3], reactive programming (RP) tries to solve the problem of intensive request. The 4 major characteristics of RP[1] are: responsive, resilient, scalable, and message-driven.
Responsive
Basically, responsiveness requires the application to response quickly, no matter in normal case or in face of node failures. This is also the reason for using reactive programming.
Resilient
Resilient requires application to tolerate some failures. In details, it can be resilience on external dependencies, that is to operate normally and securely even when the external dependency becomes wild; resilient performance, no huge increase in response delay under thundering herd effect; and resilient storage, like persistent storage in face of failures.
Scalable
A common problem for nowadays web application. Often times you want your application to be able to scale out, but not burning your brain cell for crazily complicated solution. Reactive programming makes it easier to scale out, fortunately.
Message-driven
Most of the applications transferred to reactive programming may be using observer pattern before, for which the message-driven model perfectly fits. In message-driven model, there can be combination of event-driven and actor-based.
Event-driven can be used to handle the sequential order of operations. An imperative style will implement it with callbacks, which makes caller wait for the come-back of the calling function. Another potential problem of event-driven is callback-hell[4], where the recipients of messages are anonymous callbacks instead of addressable recipients[1]. So the actor model is necessary.
For Reactive programming, there are some tools to use, like Rx (Reactive extension, and here is an excellent tutorial for RxJS) and Akka (a toolkit for building applications using the Actor pattern in Scala or Java).
Logo of ReactiveX