Redis in Docker

Running and Securing Redis

docker run -d --name cache \
  -v redisData:/data \
  -p 6379:6379 \
  redis:7-alpine \
  redis-server --requirepass strongpass --appendonly yes

protected-mode exists precisely for this shape of deployment: with no password set, Redis refuses connections from outside the local interface. Exposing 6379 without --requirepass gives anyone a writable key-value store holding your sessions — the most common container compromise pattern. Health checks must authenticate: redis-cli -a strongpass ping returns PONG only when auth succeeded.

Persistence Choices

Redis offers two mechanisms, and combining them is normal:

redis-server --appendonly yes --save 900 1 --save 60 100

Snapshots and the AOF live under /data, so the named volume from the first example is what makes either one survive a restart. For a pure cache you can set --save "" and skip AOF entirely — the data is rebuildable, and disk I/O on every write is wasted.

Caching Pitfalls and Interview Angles

Unbounded memory. Without maxmemory, Redis grows until the container OOMs. Set a ceiling and an eviction policy:

redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru

allkeys-lru is right for a cache (any key may go); noeviction is right when Redis is the source of truth and writes must fail loudly instead of silently dropping data.

Sessions vs cache. Session stores need AOF or replication — evicting a logged-in user is a different failure than losing a hot query result.

Interview: defend the eviction policy against the workload, explain RDB/AOF durability in seconds of possible loss, and describe how you would run Redis for HA (replica + Sentinel or Cluster).