I like Redis Software’s raw speed and how effortlessly it helps me solve concurrency headaches. Its lightweight, fast in-memory operations, including atomic INCR and EXPIRE commands, let me keep rate-limit counters accurate across nodes without race conditions or heavy database queries. The sub-millisecond speed and atomic counter and expiration updates make it straightforward to build reliable rate limiters, scale our API infrastructure, and reduce backend friction. Using Redis as a shared in-memory database keeps the counters in one place, and I also get caching benefits. I found setup very easy alongside Kong: its built-in Redis plugins meant I didn’t have to write custom middleware, and getting the Redis instance running and configured took little time. Review collected by and hosted on G2.com.

The biggest pain point for me with Redis Software in production is managing memory and eviction policies under heavy write loads. Since everything lives in RAM, I can hit memory limits faster than expected if my cache strategy isn’t tightly dialed in, and poorly configured eviction policies or TTLs can wipe out important rate-limiting counters or active session data. Persistence and state recovery also take some decision-making: I have to weigh the performance overhead of RDB snapshots against the data safety of AOF logs, and if persistence isn’t configured right, a crash can mean losing a few seconds of counter data and briefly skewing rate limits. Getting the setup production-ready took care with memory limits, eviction policies, and persistence settings. Review collected by and hosted on G2.com.