Redis Interview Questions

• appendfsync always/everysec/no — durability vs latency spectrum; everysec default losing ≤1s on crash.
• AOF rewrite forks child replaying current state into compact new file; copy-on-write memory spike during rewrite is the ops surprise (plan headroom ~2x dataset).
• auto-aof-rewrite-percentage triggers sizing; monitor aof_last_bgrewrite_status.

---

• Asynchronous by default: replicas stream replication feed; WAIT command provides sync acknowledgment option (latency cost).
• Failover loses unreplicated writes — min-replicas-to-write guards accepting writes without healthy replicas.
• Replicas are read-only serve reads; read-replica staleness visible via master_repl_offset deltas.

---

• Sentinel: HA for single-master topology (monitoring, automatic failover, client discovery). Data fits one node; scaling = vertical + read replicas.
• Cluster: automatic sharding across 16384 hash slots; multi-key ops require same slot (hash tags {}); resharding online. Choose Sentinel for simplicity till dataset/QPS demands sharding; Cluster adds client complexity everywhere.

---

• CRC16(key) mod 16384 assigns slots; MOVED/ASK redirects guide clients.
• Hash tags {user42}.profile and {user42}.cart co-locate related keys enabling MGET/Lua across them.
• Resharding migrates slots live via CLUSTER SETSLOT migrating/importing + MIGRATE COPY batches.

---

• Script executes atomically mid-command-stream — perfect check-and-set sequences (rate limiter, token bucket).
• Constraints: no external reads besides KEYS/ARGV passed (cluster-safe requirement), deterministic scripts only (no random/time without effects flags), script timeout kills blocking.
• SCRIPT LOAD + EVALSHA avoids resending bodies; NOSCRIPT fallback handling standard in clients.

---

• Single I/O thread processes command queue atomically (I/O threads parallelize networking in Redis 6+, execution remains serialized) → per-command O(N) costs stall EVERYTHING.
• Latency breakers to audit: KEYS/Large DEL/SLOW Lua/Big ZADD batches — SLOWLOG + LATENCY HISTORY diagnose.
• Client-side pipelining multiplies throughput without atomicity changes; MULTI differs (queued atomicity).

---

• RESP3 adds out-of-band push messages separate from reply ordering — foundation of CLIENT TRACKING invalidations.
• Tracking modes: exact keys / prefix broadcast; redirect option lets a dedicated tracking connection serve others.
• Failure modes: invalidation floods overwhelming slow clients; namespace design + batching mitigates.

---

• Subjective down (sdown) per sentinel timeout → objective down (odown quorum) → leader sentinel election (raft-ish epoch bump) → replica promotion selection (priority, offset freshness) → reconfiguration propagation.
• Split-brain guards: min-replicas-to-write + min-replicas-max-lag cause old-master writes to REJECT during partition, bounding loss window.
• Client responsibility: re-query sentinels on role errors; idempotent operations assumed across lost-write windows.

---

• Nodes gossip cluster bus (port+10000) sharing slot ownership epochs; config epoch resolves conflicts.
• Migration: SETSLOT MIGRATING on source → IMPORTING on target → loop MIGRATE keys (blocking source ops per key) → SETSLOT NODE finalized; ASK redirection during transit honored by smart clients.
• Safety: MIGRATE is atomic per key (dump+restore+del), but application multi-key assumptions break mid-reshard — hash tags mandatory discipline.

---

Reality: streams give at-least-once. Exactly-once illusion assembled:

• Dedup store: processed-id SETNX within same transaction as effect (Lua combining effect+mark atomically when effect target is redis itself).
• External-effect dedup: transactional outbox pattern — stream entry written inside DB transaction via CDC relay instead of direct XADD.
• PEL reclaim (XAUTOCLAIM) with min-idle-time prevents zombie ownership; delivery counters route poison entries to dead-letter stream.

---