williamzujkowski/Redis Database Architect

Purpose & When-To-Use

Invoke this skill when designing, reviewing, or optimizing Redis database architectures for applications requiring sub-millisecond latency, high-throughput caching, session management, real-time analytics, or distributed data structures.

Trigger Conditions:

• "Design a Redis caching layer for application]"
• "Which Redis data structure should I use for use case]?"
• "Configure Redis for high availability with SLA]"
• "Optimize Redis memory usage for data volume]"
• "Design rate limiting with Redis"
• "Plan Redis Sentinel vs Cluster for requirements]"
• "Migrate from Redis old version] to 8.0"

Out of Scope:

• PostgreSQL/MongoDB database design (use database-postgres-architect or database-mongodb-architect)
• Message queue architecture (use integration-messagequeue-designer)
• General database migration (use database-migration-generator)

Pre-Checks

1. Time Normalization: Compute NOW_ET using NIST/time.gov semantics (America/New_York, ISO-8601).
2. Input Validation:

• Use case specified (caching, session, analytics, pub/sub, queue)
• Data access patterns described (read/write ratio, TTL, hit rate)
• Data volume estimates available (keys, memory, throughput)

1. Version Check: Redis version specified (default to 8.0 if not provided).
2. Deployment Context: Cloud provider or self-hosted, resource constraints (RAM, CPU, network).
3. Existing Setup: If optimizing existing Redis, request current configuration and redis-cli INFO output.

Abort Conditions:

• No use case or access patterns provided → emit TODO list with required inputs.
• Memory requirements completely unknown → warn that sizing will be generic.

Procedure

T1: Quick Cache Strategy & Data Structure Selection (≤2k tokens)

Use Case: Fast path for common scenarios (80% of requests).

Steps:

1. Identify Use Case Category:

• Caching: Cache-aside (lazy loading) for read-heavy workloads.
• Session Storage: Strings or Hashes with TTL for user sessions.
• Rate Limiting: Sorted Sets or Strings with INCR + EXPIRE.
• Leaderboards: Sorted Sets with ZADD + ZRANGE.
• Pub/Sub: Redis Streams or Pub/Sub channels.
• Task Queue: Lists with LPUSH + BRPOP or Redis Streams.

1. Select Data Structure:

| Use Case | Recommended Structure | Key Commands | Memory Efficiency | |----------|----------------------|--------------|-------------------| | Simple key-value cache | String | GET, SET, SETEX, TTL | Baseline | | Structured objects (user profiles) | Hash | HGET, HSET, HGETALL | 50-70% savings vs strings | | Recent items (activity feed) | List | LPUSH, LRANGE, LTRIM | Efficient for ordered data | | Unique items (tags, followers) | Set | SADD, SMEMBERS, SINTER | Deduplication | | Ranked items (leaderboards) | Sorted Set | ZADD, ZRANGE, ZRANK | Score-based sorting | | Event streams (logs, messages) | Stream | XADD, XREAD, XGROUP | Append-only, consumer groups | | Probabilistic (unique counts) | HyperLogLog | PFADD, PFCOUNT | 0.81% error, 12 KB max | | Membership testing (spam filter) | Bloom Filter | BF.ADD, BF.EXISTS | Space-efficient (Redis 8.0) |

1. Quick Wins: Provide 1-3 immediate optimizations with estimated impact.

• Example: "Use Hashes instead of JSON strings → 60% memory reduction"
• Example: "Set maxmemory-policy allkeys-lru → prevent OOM errors"
• Example: "Enable AOF with fsync everysec → 30% lower write latency"

Output: Use case mapping, data structure selection, top 3 quick wins.

T2: Complete Architecture Design (≤6k tokens)

Use Case: Comprehensive architecture for production deployments.

Steps:

1. Caching Strategy Selection

Caching Patterns:

| Pattern | Description | Pros | Cons | Best For | |---------|-------------|------|------|----------| | Cache-Aside (Lazy Loading) | App checks cache first, loads from DB on miss, populates cache | Flexible, cache only what's needed | First query slow (cache miss), stale data risk | Read-heavy apps, infrequent updates | | Write-Through | App writes to cache, cache synchronously writes to DB | Strong consistency, simple invalidation | Slower writes (sync), cache all writes | Write-heavy, consistency critical | | Write-Behind (Write-Back) | App writes to cache, cache asynchronously writes to DB | Fast writes (async), batch DB writes | Potential data loss on failure, eventual consistency | High write throughput, accept eventual consistency |

Cache-Aside Example (Most Common):

python
def get_user(user_id):
    # 1. Check cache
    user = redis.get(f"user:{user_id}")
    if user:
        return json.loads(user)  # Cache hit

    # 2. Cache miss: load from database
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)

    # 3. Populate cache with TTL
    redis.setex(f"user:{user_id}", 3600, json.dumps(user))  # 1 hour TTL
    return user

Write-Through Example:

python
def update_user(user_id, data):
    # 1. Write to cache
    redis.hset(f"user:{user_id}", mapping=data)

    # 2. Synchronously write to database
    db.execute("UPDATE users SET ... WHERE id = ?", user_id)

    # Cache and DB consistent

Cache Consistency Models:

• Strong Consistency: Write-through (cache + DB updated synchronously).
• Eventual Consistency: Write-behind (cache updated first, DB later).
• TTL-based Expiry: Cache-aside with Time-To-Live (auto-invalidation).

2. Data Structure Optimization

Memory Efficiency Techniques:

1. Use Hashes for Structured Data (50-70% savings):

redis
# Instead of multiple string keys (inefficient):
SET user:1000:name "Alice"
SET user:1000:email "alice@example.com"
SET user:1000:age "30"

# Use a single hash (efficient):
HSET user:1000 name "Alice" email "alice@example.com" age 30
HGETALL user:1000

1. Sorted Sets for Ranked Data (Leaderboards):

redis
# Add players with scores
ZADD leaderboard 9500 "player1" 8200 "player2" 7800 "player3"

# Get top 10 players
ZRANGE leaderboard 0 9 WITHSCORES REV

# Get player rank
ZRANK leaderboard "player1"

1. Streams for Event Processing (Redis 8.0 Enhanced):

redis
# Add event to stream
XADD events * type "login" user_id 1000 timestamp 1730000000

# Read events (consumer group)
XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS events >

1. HyperLogLog for Unique Counts (0.81% error, 12 KB max):

redis
# Count unique visitors
PFADD visitors:2025-10-26 "user1" "user2" "user1"  # Deduplication
PFCOUNT visitors:2025-10-26  # Returns ~2 (unique count)

1. Bloom Filter for Membership Testing (Redis 8.0):

redis
# Create bloom filter with 10000 capacity, 1% error rate
BF.RESERVE spam_filter 0.01 10000

# Add emails
BF.ADD spam_filter "spam@example.com"

# Check membership (false positive possible, no false negative)
BF.EXISTS spam_filter "spam@example.com"  # Returns 1
BF.EXISTS spam_filter "real@example.com"  # Returns 0

3. Eviction Policy Configuration

8 Eviction Policies (Redis 8.0):

| Policy | Target Keys | Algorithm | Best For | |--------|-------------|-----------|----------| | noeviction | N/A (errors on OOM) | N/A | Persistent data, cannot afford data loss | | allkeys-lru | All keys | Least Recently Used | General cache, all keys eligible | | volatile-lru | Keys with TTL | Least Recently Used | Mixed workload (cache + persistent) | | allkeys-lfu | All keys | Least Frequently Used | Hotspot-heavy workloads (Redis 8.0: 16x faster) | | volatile-lfu | Keys with TTL | Least Frequently Used | Mixed workload with frequency preference | | allkeys-random | All keys | Random | Uniform access patterns | | volatile-random | Keys with TTL | Random | Simple TTL-based expiry | | volatile-ttl | Keys with TTL | Shortest TTL first | Expire soonest keys first |

Configuration Example:

redis
# Set maximum memory to 4 GB (70-80% of 6 GB system RAM)
CONFIG SET maxmemory 4gb

# Set eviction policy to allkeys-lru
CONFIG SET maxmemory-policy allkeys-lru

# Verify
CONFIG GET maxmemory
CONFIG GET maxmemory-policy

Redis 8.0 Eviction Improvements:

• 16-slot eviction pool (improves key selection quality).
• allkeys-lfu: 16x faster query processing for frequency-based eviction.

4. Persistence Configuration

3 Persistence Options:

| Option | Mechanism | Durability | Performance | Use Case | |--------|-----------|------------|-------------|----------| | RDB (Snapshots) | Point-in-time snapshots at intervals | Lose data since last snapshot | Fast (async), compact files | Backups, can tolerate data loss | | AOF (Append-Only File) | Log every write operation | Lose ≤1 sec of data (fsync everysec) | Slower writes, larger files | Durability critical | | Hybrid (RDB + AOF) | RDB snapshots + AOF log | Best of both | Balanced | Production (Redis 7.8.2+) |

RDB Configuration:

redis
# Save snapshot every 900s if ≥1 key changed
# Save snapshot every 300s if ≥10 keys changed
# Save snapshot every 60s if ≥10000 keys changed
save 900 1
save 300 10
save 60 10000

AOF Configuration (Recommended):

redis
# Enable AOF
appendonly yes

# fsync policy (choose one):
# - always: fsync every write (slowest, most durable)
# - everysec: fsync every second (30% lower latency, lose ≤1s data)
# - no: let OS decide (fastest, lose more data on crash)
appendfsync everysec

# AOF rewrite (compact log when 100% larger than last rewrite)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Hybrid Persistence (Redis 7.8.2+, recommended for Redis 8.0):

redis
# Enable both RDB and AOF
save 900 1
appendonly yes
appendfsync everysec

# Redis performs RDB snapshots + AOF log for best durability

5. High Availability Architecture

Redis Sentinel (Failover & Monitoring):

Use Case: High availability for single master, automatic failover, service discovery.

Architecture:

• Minimum: 3 Sentinel nodes (majority voting for failover).
• Topology: 1 master + 2 replicas + 3 Sentinel processes (can co-locate).
• Failover Time: Typically 10-30 seconds (configurable).

Configuration:

redis
# sentinel.conf
sentinel monitor mymaster 192.168.1.100 6379 2  # 2 = quorum (majority of 3 sentinels)
sentinel down-after-milliseconds mymaster 5000   # Declare master down after 5s
sentinel parallel-syncs mymaster 1               # Sync 1 replica at a time during failover
sentinel failover-timeout mymaster 10000         # Failover timeout 10s

Pros:

• Simple setup (3 nodes minimum).
• Automatic failover with master election.
• Service discovery (clients query Sentinel for current master).

Cons:

• No horizontal scaling (single master).
• All data must fit on one node.

Redis Cluster (Sharding & Scaling):

Use Case: Horizontal scaling, data partitioning across nodes, built-in HA.

Architecture:

• Minimum: 6 nodes (3 masters + 3 replicas).
• Sharding: 16384 hash slots distributed across masters.
• Topology: Each master has ≥1 replica, automatic failover per shard.

Configuration:

bash
# Create cluster with 3 masters + 3 replicas
redis-cli --cluster create \
  192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 \
  192.168.1.104:6379 192.168.1.105:6379 192.168.1.106:6379 \
  --cluster-replicas 1

Hash Slot Distribution:

• Total slots: 16384
• Example: Master1 (slots 0-5460), Master2 (5461-10922), Master3 (10923-16383)
• Key hashing: CRC16(key) mod 16384 determines slot.

Pros:

• Horizontal scaling (1000 nodes max).
• Automatic sharding and rebalancing.
• Built-in HA (no external Sentinel).

Cons:

• More complex (6 nodes minimum).
• Multi-key operations limited (keys must be on same slot or use hash tags).
• No support for SELECT database command (only DB 0).

Sentinel vs Cluster Decision Matrix:

| Requirement | Redis Sentinel | Redis Cluster | |-------------|----------------|---------------| | Data size fits on single node | ✅ Yes | Not needed | | Need horizontal scaling | ❌ No | ✅ Yes | | Simple failover only | ✅ Yes | Overkill | | High availability + sharding | ❌ No | ✅ Yes | | Minimum nodes | 3 | 6 |

6. Performance Tuning (Redis 8.0)

Redis 8.0 Performance Improvements:

• 87% faster latency (p50 latency reduction).
• 2x more operations per second (throughput).
• 16x faster query processing (allkeys-lfu eviction).
• 112% throughput improvement with I/O threading on multi-core CPUs.

Configuration Parameters:

redis
# I/O Threading (Redis 8.0 - up to 112% improvement on multi-core)
io-threads 4  # Set to number of CPU cores (max 8)
io-threads-do-reads yes  # Enable threaded reads (Redis 8.0+)

# Max clients (default 10000)
maxclients 50000

# Timeout for idle clients (default 0 = never)
timeout 300  # Close idle clients after 5 minutes

# TCP backlog (default 511, increase for high concurrency)
tcp-backlog 65535

# Disable slow commands in production (optional)
rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command CONFIG ""

# Lazy freeing (async deletion of large keys)
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes

Memory Configuration:

redis
# Set maxmemory to 70-80% of system RAM (allows OS cache)
maxmemory 6gb  # For 8 GB RAM server

# Eviction policy
maxmemory-policy allkeys-lru

# Memory sampling for eviction (default 5, higher = better accuracy, slower)
maxmemory-samples 10

Output: Complete architecture with caching strategy, data structures, eviction policy, persistence, HA topology, performance tuning.

T3: Enterprise Features & Use Case Patterns (≤12k tokens)

Use Case: Advanced patterns, multi-region, specific use cases, version migrations.

Steps:

1. Advanced Use Case Patterns

Rate Limiting (Fixed Window):

python
def is_rate_limited(user_id, limit=100, window=60):
    key = f"rate_limit:{user_id}"
    current = redis.incr(key)

    if current == 1:
        redis.expire(key, window)  # Set TTL on first request

    return current > limit  # True if over limit

Rate Limiting (Sliding Window with Sorted Set):

python
def is_rate_limited_sliding(user_id, limit=100, window=60):
    now = time.time()
    key = f"rate_limit:{user_id}"

    # Remove old entries outside window
    redis.zremrangebyscore(key, 0, now - window)

    # Count requests in window
    count = redis.zcard(key)

    if count < limit:
        redis.zadd(key, {str(uuid.uuid4()): now})  # Add new request
        redis.expire(key, window)
        return False  # Not limited

    return True  # Limited

Session Storage:

python
def create_session(user_id, session_data, ttl=3600):
    session_id = str(uuid.uuid4())
    key = f"session:{session_id}"

    # Store session as hash
    redis.hset(key, mapping={
        "user_id": user_id,
        **session_data
    })
    redis.expire(key, ttl)  # Auto-expire after 1 hour

    return session_id

Real-Time Leaderboard:

python
def update_leaderboard(player_id, score):
    redis.zadd("leaderboard", {player_id: score})

def get_leaderboard(top_n=10):
    # Get top N players with scores
    return redis.zrange("leaderboard", 0, top_n - 1, withscores=True, desc=True)

def get_player_rank(player_id):
    rank = redis.zrevrank("leaderboard", player_id)  # 0-indexed
    return rank + 1 if rank is not None else None

Pub/Sub (Real-Time Notifications):

python
# Publisher
def publish_notification(channel, message):
    redis.publish(channel, json.dumps(message))

# Subscriber
def subscribe_notifications(channel):
    pubsub = redis.pubsub()
    pubsub.subscribe(channel)

    for message in pubsub.listen():
        if message['type'] == 'message':
            data = json.loads(message['data'])
            handle_notification(data)

Task Queue (Simple FIFO):

python
# Producer
def enqueue_task(queue_name, task_data):
    redis.lpush(queue_name, json.dumps(task_data))

# Consumer (blocking pop)
def process_tasks(queue_name):
    while True:
        # BRPOP blocks until item available (timeout 0 = infinite)
        _, task_json = redis.brpop(queue_name, timeout=0)
        task = json.loads(task_json)
        process_task(task)

2. Multi-Region Deployment (Redis Enterprise)

Active-Active Geo-Replication:

• Redis Enterprise feature (not OSS).
• Conflict-free replicated data types (CRDTs).
• Bidirectional replication across regions.
• Automatic conflict resolution.

Architecture:

• Region 1: Redis cluster (3 masters + 3 replicas).
• Region 2: Redis cluster (3 masters + 3 replicas).
• Active-active replication between regions.
• Local reads/writes in each region (low latency).

Use Case: Global applications with local write requirements.

3. Migration from Redis 7.x to 8.0

Benefits of Redis 8.0:

• 87% faster latency, 2x ops/sec (accessed 2025-10-26T18:28:30-0400, Redis Blog).
• New I/O threading: 112% throughput improvement.
• Vector sets (beta), enhanced JSON, time series.
• 5 probabilistic structures: Bloom, Cuckoo, Count-min sketch, Top-k, t-digest.

Migration Strategy (Zero-Downtime):

1. Set up Redis 8.0 replica (add as slave to existing Redis 7.x master).
2. Replicate data (wait for replication lag to stabilize).
3. Test queries on Redis 8.0 replica (validate compatibility, performance).
4. Promote Redis 8.0 replica to master (use SLAVEOF NO ONE or Sentinel failover).
5. Upgrade remaining replicas (one at a time).
6. Enable Redis 8.0 features (io-threads, new data structures).
7. Monitor for 24h (rollback if issues detected).

Risks:

• Client library compatibility (ensure drivers support Redis 8.0).
• Deprecated features removed (check release notes).
• I/O threading requires tuning (set io-threads = CPU cores).

4. Monitoring & Observability

Key Metrics:

redis
# Server stats
INFO stats
# - total_commands_processed: Total commands executed
# - instantaneous_ops_per_sec: Current ops/sec
# - total_net_input_bytes, total_net_output_bytes: Network I/O
# - evicted_keys: Keys evicted due to maxmemory
# - expired_keys: Keys expired by TTL

# Memory stats
INFO memory
# - used_memory_human: Total memory used
# - used_memory_rss_human: OS-reported RSS
# - mem_fragmentation_ratio: RSS / used_memory (>1.5 = fragmentation issue)
# - maxmemory_human: Configured maxmemory limit

# Replication stats
INFO replication
# - role: master or slave
# - connected_slaves: Number of replicas
# - master_repl_offset: Replication offset (lag indicator)

# Slow log (queries >threshold)
SLOWLOG GET 10  # Last 10 slow queries
CONFIG SET slowlog-log-slower-than 10000  # Log queries >10ms

Prometheus Exporter:

• Use redis_exporter for Prometheus integration.
• Metrics: redis_uptime_in_seconds, redis_connected_clients, redis_used_memory_bytes, redis_evicted_keys_total.

Output: Advanced use case patterns, multi-region architecture, migration plan, monitoring dashboards.

Decision Rules

1. Caching Strategy:

• If read-heavy (80%+ reads) → Cache-aside (lazy loading).
• If write-heavy + strong consistency → Write-through.
• If write-heavy + eventual consistency OK → Write-behind.

1. Data Structure:

• Simple key-value → String.
• Structured object (user profile) → Hash (50-70% memory savings).
• Ordered list (activity feed) → List.
• Unique items (tags, followers) → Set.
• Ranked items (leaderboard) → Sorted Set.
• Event stream → Stream (consumer groups).
• Unique count approximation → HyperLogLog.
• Membership testing → Bloom Filter (Redis 8.0).

1. Eviction Policy:

• General cache (all keys cache) → allkeys-lru.
• Mixed workload (cache + persistent) → volatile-lru.
• Hotspot-heavy → allkeys-lfu (Redis 8.0: 16x faster).
• Cannot lose data → noeviction + monitor memory.

1. Persistence:

• Can tolerate data loss (cache) → RDB only (fast).
• Durability critical → AOF (appendfsync everysec).
• Production → Hybrid (RDB + AOF) (Redis 7.8.2+).

1. High Availability:

• Data fits on one node + need failover → Redis Sentinel (3 nodes).
• Need horizontal scaling (>100 GB) → Redis Cluster (6+ nodes).
• Global low-latency writes → Redis Enterprise Active-Active (multi-region).

1. Memory Sizing:

• Set maxmemory to 70-80% of system RAM (leave room for OS, fragmentation).
• If mem_fragmentation_ratio >1.5 → restart Redis or use CONFIG SET activedefrag yes.

Uncertainty Thresholds:

• If access patterns unclear → request cache hit rate target and read/write ratio.
• If memory highly uncertain → provide scalable architecture with Cluster plan.
• If existing Redis has issues → request INFO output and slow log analysis.

Output Contract

Required Fields:

yaml
caching_strategy:
  - pattern: "cache-aside" | "write-through" | "write-behind"
    consistency_model: "strong" | "eventual" | "ttl-based"
    cache_invalidation: string (how to invalidate stale data)

data_structures:
  - use_case: string
    structure: "string" | "hash" | "list" | "set" | "sorted_set" | "stream" | "hyperloglog" | "bloom_filter"
    key_pattern: string (e.g., "user:{user_id}")
    commands: array (Redis commands used)
    memory_efficiency: string (e.g., "50% savings vs strings")

eviction_policy:
  - maxmemory: string (e.g., "4gb")
    policy: "allkeys-lru" | "volatile-lru" | "allkeys-lfu" | "noeviction" | ...
    justification: string

persistence:
  - type: "rdb" | "aof" | "hybrid"
    rdb_config: object (save intervals) if applicable
    aof_config: object (fsync policy) if applicable
    data_loss_tolerance: string (e.g., "≤1 second")

high_availability:
  - architecture: "standalone" | "sentinel" | "cluster"
    topology: string (e.g., "1 master + 2 replicas + 3 sentinels")
    failover_time: string (e.g., "10-30 seconds")
    scaling_plan: string (if cluster)

performance_tuning:
  - io_threads: integer (Redis 8.0)
    maxclients: integer
    timeout: integer (seconds)
    lazy_freeing: boolean
    estimated_improvement: string (e.g., "87% faster latency")

memory_optimization:
  - techniques: array (hash optimization, data structure selection, etc.)
    estimated_savings: string (e.g., "60% memory reduction")

migration_plan:  # If upgrading versions
  - current_version: string
    target_version: string
    strategy: "replica promotion" | "blue-green" | "rolling upgrade"
    steps: array (migration steps)
    risks: array (potential issues)

Token Tier Minimums:

• T1: caching_strategy, data_structures (top 3), eviction_policy, quick wins.
• T2: All of T1 + persistence, high_availability, performance_tuning, memory_optimization.
• T3: All of T2 + use_case_patterns, multi-region, migration_plan, monitoring.

Examples

Cache-Aside Pattern with Hash:

python
# User profile caching (60% memory savings vs JSON string)
def get_user_profile(user_id):
    key = f"user:{user_id}"

    # Check cache (hash structure)
    if redis.exists(key):
        return redis.hgetall(key)  # Cache hit

    # Cache miss: load from database
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)

    # Populate cache with TTL
    redis.hset(key, mapping=user)
    redis.expire(key, 3600)  # 1 hour

    return user

See examples/session-storage-redis-architecture.txt for a complete session management architecture.

Quality Gates

1. Token Budgets:

• T1 response ≤2k tokens (fast path, common scenarios).
• T2 response ≤6k tokens (complete architecture).
• T3 response ≤12k tokens (enterprise features, migrations).

1. Safety Checks:

• No credentials or connection strings with passwords in output.
• Eviction policy configured to prevent OOM errors.
• Persistence enabled for durability-critical use cases.

1. Auditability:

• All data structure selections include memory efficiency justification.
• All HA architectures include failover time and scaling plan.
• All performance claims cite Redis 8.0 benchmarks with access dates.

1. Determinism:

• Same input (use case, access patterns, data volume) → same architecture recommendations.
• Data structure selection deterministic (use case mapping table).

1. Citations:

• Redis 8.0 performance: 87% faster latency, 2x ops/sec, 16x query processing (accessed 2025-10-26T18:28:30-0400, Redis Blog).
• Hash memory savings: 50-70% vs separate strings (accessed 2025-10-26T18:28:30-0400, Redis Memory Optimization).
• Caching patterns: Cache-aside, write-through, write-behind (accessed 2025-10-26T18:28:30-0400, Redis Caching).

Resources

Official Redis Documentation:

• Redis 8.0 Release Notes (accessed 2025-10-26T18:28:30-0400)
• Redis Data Types Introduction
• Redis Persistence
• Redis Sentinel
• Redis Cluster

Performance & Best Practices:

• Redis Caching Patterns (accessed 2025-10-26T18:28:30-0400)
• Redis Eviction Policies (accessed 2025-10-26T18:28:30-0400)
• Redis Memory Optimization (accessed 2025-10-26T18:28:30-0400)
• Sentinel vs Cluster Comparison (accessed 2025-10-26T18:28:30-0400)

Tools:

• RedisInsight (GUI for Redis with profiling)
• redis-cli (command-line interface)
• redis_exporter (Prometheus exporter)