Skip to content

redis.md

Latest commit

 

History

History
328 lines (204 loc) · 11.5 KB

redis.md

File metadata and controls

328 lines (204 loc) · 11.5 KB
Raw

Redis

1) Redis Core Architecture (Senior Depth)

1. How does Redis handle single-threaded execution, and why is it still fast?

Ideal answer Redis executes commands in a mostly single-threaded event loop, which avoids thread contention and context switching. It’s fast because:

  • Data is in-memory (no disk seek per operation).
  • Commands are O(1) or near-O(1) for common structures.
  • I/O is handled via non-blocking sockets + multiplexing (epoll/kqueue), so many connections can be served efficiently.

Senior notes

  • “Single-threaded” is primarily the command execution path; some tasks can be multi-threaded in modern Redis (e.g., certain background I/O/persistence), but command semantics remain sequential.

Follow-ups

  • Redis slows when commands block (big keys, slow Lua, persistence fork latency, network saturation).

2. Explain Redis persistence: RDB vs AOF. Which one would you choose in production?

Ideal answer

  • RDB (snapshot): periodically writes a point-in-time dump. Pros: compact, fast restart. Cons: can lose recent writes (between snapshots), fork can cause latency spikes.
  • AOF (append-only file): logs every write. Pros: better durability; with appendfsync everysec, typical loss window is ~1s. Cons: larger files, slower restart (replay), rewrite overhead.

Production choice

  • If I need stronger durability: AOF everysec (often with AOF rewrite).
  • If I mostly want fast restart and can tolerate some loss: RDB.
  • Common: AOF enabled + periodic RDB / hybrid, depending on ops posture and acceptable loss.

3. What happens if Redis crashes during a write?

Ideal answer It depends on persistence mode:

  • With AOF, on restart Redis replays the AOF. If the last command is partially written/corrupted, Redis can truncate/repair (depending on configuration/tools) and load up to the last valid entry—so you may lose the tail.
  • With RDB, you restore to the last snapshot → data after snapshot is lost.

With appendfsync everysec, you may lose up to ~1 second of writes on crash (OS buffers).

2) Data Structures & Internals

4. When would you choose Redis over a database as a primary store?

Ideal answer Only when the data model and durability requirements fit:

  • Ephemeral / TTL-based data: sessions, OTP, rate limits.
  • Derived / cacheable data where DB is source of truth.
  • Ultra-low latency counters/leaderboards where occasional loss is acceptable or mitigated (streaming rebuild).

If the system needs strong durability, complex queries, and strict consistency, Redis should not be the primary store; it should be a cache/accelerator.

5. Explain Redis data structures internally: Hash, Sorted Set, List

Ideal answer

  • Hash: optimized for small hashes (compact encoding) and switches to hashtable when it grows. Great for grouping fields by key (user profile, settings).
  • Sorted Set (ZSET): typically implemented with a skiplist + hash map for member→score lookup. Great for leaderboards, ranking, time-based ordering.
  • List: implemented as quicklist-like structure (linked list of compact blocks) to balance memory and speed. Good for queues, feeds (though Streams often better now).

Senior note Internal encodings change across versions; what matters in interviews is: Redis uses space-efficient encodings for small values, and upgrades to more general structures as it grows.

6. How does Redis manage memory? What happens when memory is full?

Ideal answer Redis uses an allocator (commonly jemalloc) and supports:

  • maxmemory to cap memory usage
  • eviction policies:
    • noeviction (writes fail)
    • allkeys-lru/lfu, volatile-lru/lfu (only keys with TTL), random, ttl When memory is full:
  • With eviction policy, Redis evicts keys according to the policy.
  • With noeviction, write commands that increase memory fail.

Senior angle Memory fragmentation can be a real issue; monitoring mem_fragmentation_ratio, big keys, and allocator behavior matters.

3) Redis Cluster & High Availability

7. Explain Redis Cluster. What is 16384 slots and why?

Ideal answer Redis Cluster partitions the keyspace into hash slots (fixed number: 16384) using a CRC16 hash → slot mapping. Each slot is assigned to a master node; replicas follow that master. Why fixed slots:

  • Simplifies rebalancing: move slots between nodes instead of rehashing everything.
  • Clients can route requests based on slot metadata and handle MOVED/ASK redirections.

8. What happens if a Redis master node goes down?

Ideal answer Two common HA setups:

  • Redis Sentinel (non-cluster): Sentinels detect failure, elect a leader, promote a replica, and reconfigure clients.
  • Redis Cluster: cluster nodes detect failure, and if quorum is satisfied, a replica is promoted to master and takes over the slots.

Senior pitfalls

  • Failover can cause brief unavailability and potential data loss if replication lag exists.
  • Split-brain can happen if quorum/partition issues; correctness depends on topology and settings.

9. How does Redis handle resharding?

Ideal answer In Cluster, resharding is slot migration:

  • Pick slots to move from source master → target master.
  • During migration, clients may get ASK redirections; after migration, MOVED. Impact:
  • Increased latency during migration due to extra hops/redirects.
  • Operational complexity: careful planning to avoid hot-slot imbalance.

4) Distributed Locking (Very Important)

10. How would you implement a distributed lock using Redis?

Ideal answer Use a single atomic command:

  • Acquire: SET lock_key unique_value NX PX ttl
    • NX ensures only one owner
    • PX ttl ensures auto-expire

Release safely:

  • Only the owner should unlock → compare the stored value with your unique_value
  • Use Lua to check-and-del atomically:
    • If value matches → DEL
    • Else do nothing

Senior pitfalls

  • TTL too short → lock expires while work still running → two owners
  • TTL too long → slow recovery if owner dies
  • Always pick unique values (UUID) per lock holder.

11. What is Redlock? Do you trust it?

Ideal answer Redlock is an algorithm for locks across multiple independent Redis masters (acquire lock in a majority within a time window). Senior stance:

  • It improves safety under some failure modes, but network partitions, clock drift, and GC pauses can still break assumptions.
  • For money-critical or strict correctness (e.g., banking ledger), I’d prefer DB constraints/transactions or a consensus system (ZooKeeper/etcd) rather than Redis locking.

12. Can Redis locks be used for idempotency?

Ideal answer Yes, but lock ≠ idempotency key.

  • Idempotency is about “same request → same effect/result.”
  • A lock only serializes execution; retries after lock expiry can still duplicate effects.

Better pattern:

  • Store idempotency key with result (or status) in Redis/DB.
  • Use SETNX/SET NX PX to “claim” processing.
  • Persist final outcome so retries can return the same response without reprocessing.

5) Consistency, Transactions & Lua

13. Does Redis support transactions? Are they ACID?

Ideal answer Redis has MULTI/EXEC:

  • Commands queued then executed sequentially.
  • It is atomic (no interleaving during EXEC), but not ACID:
    • No rollback if a command fails at runtime.
    • No isolation like DB levels beyond single-thread sequencing. For conditional updates, use Lua scripts or WATCH (optimistic concurrency).

14. Why and when would you use Lua scripts in Redis?

Ideal answer Lua scripts provide:

  • Atomic multi-step operations (check then set, conditional increments, etc.)
  • Fewer round trips → lower latency Use cases:
  • Safe unlock
  • Rate limiter token bucket
  • Compare-and-swap updates

Risk Lua runs in the main thread; long scripts block Redis → must keep scripts short and predictable.

6) Caching Patterns (Real Production)

15. Explain cache-aside vs write-through vs write-behind

Ideal answer

  • Cache-aside: app reads cache; on miss reads DB then populates cache. Writes go to DB then invalidate/update cache.
    • Pros: simple, flexible
    • Cons: stale data risk, stampede on hot miss
  • Write-through: app writes cache, cache writes DB synchronously.
    • Pros: cache always warm/consistent
    • Cons: added write latency, cache becomes critical path
  • Write-behind: app writes cache; cache flushes to DB asynchronously.
    • Pros: very fast writes
    • Cons: risk of data loss, complex recovery

16. How do you prevent cache stampede?

Ideal answer Use one or combine:

  • Mutex / lock on miss: only one request rebuilds, others wait/fallback.
  • Request coalescing: collapse concurrent rebuilds.
  • Early refresh / soft TTL: refresh before expiration in background.
  • Jittered TTL: avoid synchronized expirations.

17. How do you handle cache penetration?

Ideal answer Cache penetration = many requests for non-existing keys hitting DB. Mitigations:

  • Cache nulls (short TTL) for misses
  • Bloom filter in front
  • Rate limit / WAF for abusive patterns

7) Performance & Scalability

18. Why can Redis become slow even if CPU usage is low?

Ideal answer Because bottlenecks may be:

  • Network saturation (NIC/packet processing)
  • Blocking commands on big keys
  • Fork/persistence causing latency spikes (copy-on-write overhead)
  • Disk I/O during AOF rewrite
  • Slow clients / output buffer issues

19. What is a “big key” problem? How do you detect and fix it?

Ideal answer A big key is a key with very large value or huge collection (big hash/zset/list). Problems:

  • Single command takes long time, blocks event loop
  • Replication and persistence become heavy
  • Memory fragmentation & eviction inefficiency

Detection:

  • SCAN + MEMORY USAGE <key>
  • Monitor latency/slowlog Fix:
  • Split into multiple keys (sharding by userId:part)
  • Use better structures (Streams instead of huge Lists)
  • Limit per-key size and enforce via app logic

8) Security & Ops

20. How do you secure Redis in production?

Ideal answer

  • Never expose Redis publicly
  • Use private network/VPC, security groups/firewall
  • Enable AUTH/ACL (least privilege)
  • Enable TLS if crossing untrusted networks
  • Disable dangerous commands in shared environments (or restrict via ACL)
  • Monitor config drift

21. How do you monitor Redis health?

Ideal answer Key signals:

  • Latency percentiles (p95/p99) and slowlog
  • Memory usage, fragmentation ratio
  • Evictions and keyspace hits/misses
  • Replication lag, number of connected clients
  • AOF rewrite status / fork time spikes

Alerting:

  • sustained high latency
  • evictions increasing unexpectedly
  • replication lag growing
  • near maxmemory + rising fragmentation

9) Scenario-Based (Interview Favorite)

22. You use Redis as cache. DB is down. What happens?

Ideal answer Cache can keep reads alive temporarily if data is already cached. But:

  • Cache-aside misses will fail (can’t load from DB). Mitigations:
  • Serve stale cache (stale-while-revalidate)
  • Circuit breaker: stop DB calls, degrade gracefully
  • Fallback default responses for non-critical endpoints
  • Pre-warm critical keys / protect hot paths

23. Redis is up, but latency spikes randomly. How do you debug?

Ideal answer I’d check in order:

  1. Redis metrics: INFO, latency stats, slowlog
  2. Persistenc