Redis started as a performance optimisation. Then production started depending on it.

This is an important transition in a Rails application.

Initially, we used caching to reduce database load:
* Frequently accessed data
* Expensive queries
* Session data
* Background job queues

Everything worked well.

But over time, more application behaviour started depending on Redis.

That's when the question changed from:
“How much faster does Redis make the application?”

to:
“What happens if Redis is unavailable?”

This is where AWS ElastiCache decisions become important.

Redis makes sense when you need richer data structures, persistence options, pub/sub or more advanced caching patterns.

Memcached can be a better fit when you only need a simple, distributed cache.

But the bigger decision is architectural.

If Redis is only a cache, your Rails application should have a fallback when it disappears.

If Redis is also handling Sidekiq queues, sessions or other critical workloads, an outage can become much more serious.

Important learning:
The moment a cache becomes critical to application behaviour, stop treating it as “just a cache”.

Define:
* What happens when it goes down?
* Which data can be rebuilt?
* Which workloads share the cluster?
* How much memory do we actually need?
* What should be monitored?

Caching improves performance.

Dependency design protects reliability.