Certificate

# ===== Skills checklist =====
# After the Redis track you should be able to:
# [x] Pick the right data type for an access pattern
# [x] Set TTLs on every key that needs one; understand eviction policies
# [x] Build rate limiters (fixed + sliding window)
# [x] Build a distributed lock (SET NX PX + Lua release)
# [x] Build a session store with sliding TTL
# [x] Build a cache with dogpile protection
# [x] Use Streams + consumer groups for at-least-once jobs
# [x] Run leaderboards with sorted sets
# [x] Use HyperLogLog for approximate unique counts
# [x] Use geospatial commands for proximity queries
# [x] Configure persistence (RDB + AOF) and replication
# [x] Secure with ACLs + TLS + rename-command
# [x] Monitor INFO + slow log + latency + Prometheus exporter
# [x] Plan capacity: maxmemory + eviction policy + working set

# ===== Bookmark =====
# - https://redis.io/docs                      official docs
# - https://redis.io/glossary                  data-type semantics
# - https://github.com/redis/redis             source code, follow the commits
# - https://github.com/redis/ioredis           Node client
# - https://github.com/redis/redis-py          Python client
# - 'Redis Best Practices' on the Redis blog

# ===== Portfolio project (4-8 hours) =====
# Build a Redis-backed coordination service for a small web app:
# 1) Rate limit (sliding window) on a write endpoint
# 2) Idempotency keys (SET NX EX) on POST /orders
# 3) Distributed lock around a job that runs on schedule
# 4) Cached aggregate with dogpile protection
# 5) Streams + consumer group for an async notifications worker
# 6) Health endpoint that reports Redis hit rate + memory usage
# 7) Tests that run against a real Redis (testcontainers)
# 8) Dockerfile + compose with TLS + AUTH + persistence
# 9) README explains each pattern + how to extend

# Bonus:
# - Helm chart for the service
# - Grafana dashboard with Redis metrics
# - Chaos test: kill Redis mid-write, verify retry behavior

# ===== What 'good' looks like =====
# - Every key has a TTL (no unbounded growth)
# - Locks released via Lua (no risk of releasing someone else's lock)
# - Consumer group survives a worker crash (pending entries get redelivered)
# - Hit rate > 90% in load tests
# - No 'KEYS *' in the codebase; only SCAN
# - Maxmemory + allkeys-lru configured

# ===== Common mistakes to avoid =====
# - Using PUBSUB for durable job delivery (no replay)
# - 'I'll add a TTL later' -> memory bloat
# - Storing 1MB JSON blobs in strings
# - One client for many tenants without keyspace prefixes
# - Production Redis exposed on the public internet

# ===== Next steps =====
# - Redis Cluster: sharding across many nodes
# - RedisJSON / RediSearch / RedisGraph modules
# - Lua scripting for atomic multi-key operations
# - Sidekiq / BullMQ / RQ / arq — production queues built on Redis
# - Read 'Redis in Action' (Carlson)

# ===== Self-test =====
# Can you:
# 1) Pick the right data type for any 'we need X' description in seconds?
# 2) Explain why SET NX PX + Lua release prevents the 'released someone else's
#    lock' race?
# 3) Diagnose a memory growth issue by reading INFO and SLOWLOG?
# you have completed the track. Ship the portfolio piece and call it done.

# ===== Track wrap-up =====
# Redis is the right answer to many 'we need a fast in-memory thing' questions:
# - Cache
# - Rate limiter
# - Session store
# - Job queue (Streams)
# - Distributed lock
# - Leaderboard
# The discipline that matters: every key has a TTL, every lock has a release,
# every queue has a consumer group + retry policy. Get those right and Redis
# becomes the most reliable piece of your stack.

# /certificate/redis