Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Stand up a production-grade Redis deployment and document the operational decisions. Include: (1) PERSISTENCE configured deliberately (RDB and/or AOF) with the durability-vs-performance trade-off explained for your use case; (2) HIGH AVAILABILITY — a primary with replicas plus Redis Sentinel for automatic failover (demonstrate a failover), OR a Redis Cluster if you need sharding (explain hash slots and multi-key/hash-tag implications); (3) an EVICTION policy + maxmemory chosen correctly for whether this Redis is a cache (allkeys-lru/lfu) or a datastore (noeviction); (4) a SECURITY baseline — ACLs/AUTH, TLS, bound to a private network/firewalled, dangerous commands renamed, NOT exposed to the internet; and (5) monitoring (SLOWLOG, INFO metrics, latency). Explain when you'd reach for Valkey instead.
Replication + Sentinel auto-failover demonstrated (or a justified Cluster with hash-slot/hash-tag understanding); replication-is-async/eventual understood.
RDB/AOF chosen with the trade-off explained; eviction policy + maxmemory match cache-vs-datastore correctly (noeviction for a DB).
ACLs/AUTH + TLS + private binding/firewall; dangerous commands restricted; never exposed to the public internet.
SLOWLOG/INFO/latency monitoring; understands single-threaded bottlenecks; can say when Valkey fits.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A production Redis: HA, persistence, eviction & security ## Goal Stand up a production-grade Redis deployment and document the operational decisions. Include: (1) PERSISTENCE configured deliberately (RDB and/or AOF) with the durability-vs-performance trade-off explained for your use case; (2) HIGH AVAILABILITY — a primary with replicas plus Redis Sentinel for automatic failover (demonstrate a failover), OR a Redis Cluster if you need sharding (explain hash slots and multi-key/hash-tag implications); (3) an EVICTION policy + maxmemory chosen correctly for whether this Redis is a cache (allkeys-lru/lfu) or a datastore (noeviction); (4) a SECURITY baseline — ACLs/AUTH, TLS, bound to a private network/firewalled, dangerous commands renamed, NOT exposed to the internet; and (5) monitoring (SLOWLOG, INFO metrics, latency). Explain when you'd reach for Valkey instead. ## Acceptance criteria - [ ] HA & failover: Replication + Sentinel auto-failover demonstrated (or a justified Cluster with hash-slot/hash-tag understanding); replication-is-async/eventual understood. - [ ] Persistence & eviction: RDB/AOF chosen with the trade-off explained; eviction policy + maxmemory match cache-vs-datastore correctly (noeviction for a DB). - [ ] Security: ACLs/AUTH + TLS + private binding/firewall; dangerous commands restricted; never exposed to the public internet. - [ ] Monitoring & judgment: SLOWLOG/INFO/latency monitoring; understands single-threaded bottlenecks; can say when Valkey fits. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.