Aziz,
Redis is in the NoSQL database category. Specifically, it is a Key/Value database within the NoSQL category. There is nothing in the Reactive design principles that would lead you to choose Redis over CouchDB, for instance. They both have very similar Reactive properties. For that matter, there is nothing in the Reactive philosophy that what lead you to choose a NoSQL database over a SQL database, per se.
The decision is not on the specific API of the DB, but on how the specific database in question will behave in "Reactive" terms. Reactive software should have the following properties:
- Responsive. This means that component interactions need to be managed and time-outs and error handling be put into place so that either success or failure happens quickly. This is an issue of design and programming rather than of technology. .
- Resilient. In practice, this basically means containerized. The real requirement is fault tolerance. While their are other methods than containers for achieving this goal, in combination with "Elastic" this is generally taken to imply containers.
- Elastic. In practice, this basically means some kind of horizontal scaling method rather than a vertical one so that capacity can be scaled over a very wide range. So basically, either network or Cloud Native designs.
- Message Driven. The goal is to have asynchronous interactions between components so that an individual component cannot be held captive by waiting on another component.
As you can see, none of these design criteria would require Redis over another Database. In fact, no database is going to meet the last criteria. In order to by asynchronous to support Responsiveness, an asynchronous "wrapper" service would need to be put in front of any database call.
Here is a linke to the "Reactive Manifesto":
Reactive Manifesto
Regards,
Glen Brumbaugh