What it is
Redis is an in-memory data store. It keeps data in RAM, so reads and writes take well under a millisecond, and it can save to disk so data survives a restart. It is a key-value store, but values can be strings, lists, sets, hashes, sorted sets and streams, each with its own commands. Keys can be given an expiry time so they clean themselves up.
It is widely used as a cache in front of a slower database, for session storage, job queues, leaderboards and counters. Because it is fast and supports atomic increments with expiry, it is a common place to keep rate-limit counters that several app processes need to share. Client libraries exist for almost every language, including node-redis for Node.js.
How I use it
- Shared rate limiting for sign-in and forgot-password requests in my family tree app, counted per IP address and email.
- Ran as its own container in Docker Compose next to the API on a small EC2 instance.
- If Redis is not configured, the app falls back to in-memory counters instead of failing.
- The serverless relaunch on AWS Lambda runs without Redis, using that fallback.
Redis is the right tool when several processes need to share small, fast-changing values such as counters or sessions. I used it for rate limiting so the limits held no matter which process served the request. I also made it optional, because a small app should not fall over just because its cache is missing.
Questions
How do you stop brute-force sign-in attempts?
With rate limits on sign-in and password-reset requests, counted per IP address and email. In my family tree app the counters lived in Redis so every API process shared them, with an in-memory fallback when Redis is absent.
Do you always need Redis?
No. It earns its place when several processes share state. My serverless relaunch on Lambda runs without it, so I designed the app to work either way.