Redis is one of the most misused tools in software development — added as a caching layer when it is not needed, or avoided when it would dramatically simplify architecture. Here is an honest assessment.
What Redis Actually Is
Redis is an in-memory key-value store with optional persistence. “In-memory” means it is fast (microsecond reads/writes) but data lives in RAM. “Optional persistence” means you can configure it to write snapshots or append-only logs to disk — but it is primarily designed as a fast ephemeral store, not a database of record. Think of it as a very fast shared dictionary that all your application servers can access.
When Redis Makes Sense
Caching: The canonical use case. Cache expensive database queries or API responses. TTL (time-to-live) expiry is built in. Session storage: Storing web session data (user auth state, shopping cart) that needs to be shared across multiple server instances. Rate limiting: Increment a counter per IP per minute — Redis’s atomic INCR with EXPIRE is 3 lines of code. Pub/Sub messaging: Redis pub/sub works for simple real-time messaging between services (though Kafka is better for durability). Leaderboards: Redis sorted sets (ZADD, ZRANGE) make leaderboards trivially simple.
When Redis Does Not Make Sense
Primary data storage for anything important — if Redis goes down and you have not set up persistence properly, data is gone. Replacing a proper database — Redis has no joins, no ACID transactions, and no complex query support. Adding complexity for small-scale applications — if you have one server and under 10,000 users, Redis adds operational overhead without meaningful benefit.
Managed Redis Options
AWS ElastiCache, Upstash (serverless Redis, pay per request, excellent free tier), Redis Cloud, and Railway all offer managed Redis. For most applications, Upstash’s free tier (10,000 commands/day) is sufficient for caching and rate limiting without any infrastructure management.
