Redis Internals: The Senior Engineer's Review & Interview Guide

1. TCP Server Behavior & Protocol (RESP)

Internal Architecture & Components

Redis uses a single-threaded Event Loop that manages File Descriptors (Sockets). Incoming data is buffered in the Query Buffer (RESP format).

High Concurrency & Backpressure

• Behavior: Redis handles 10k+ connections without thread context switching.
• Backpressure Handling: If a client is too fast, the query buffer grows until it hits a limit, then Redis stops reading from that socket to protect memory.

Bottlenecks & Scaling Limitations

• Bottlenecks: CPU cache misses and network interrupt handling.
• Scaling: Vertical scaling (more cores) doesn't help the main thread; horizontal scaling (Clusters) is required.

Redis vs. Our Implementation

• What we Simplified: We use Node.js net module; Redis uses a custom raw ae library.
• Why Redis is Optimized: It uses Zero-Copy Reads where the kernel data is mapped directly into the app memory.

2. Event Loop and IO Multiplexing

Algorithms Used

Uses the Reactor Pattern and underlying kernel algorithms like epoll (Linux) or kqueue (Mac). These are $O(1)$ algorithms for finding active sockets.

Why Redis is Optimized

It prioritizes "Time Events" (like TTL cleanup) and "File Events" (like Client Queries) in a single loop, ensuring nothing stays in the queue for more than 100ms.

Scaling Limitations

A single Event Loop can eventually hit a ceiling of ~1 million requests/sec on modern hardware. Beyond this, even Redis must use I/O Threads (Redis 6.0+).

3. Data Structures & Memory Behavior

Data structures (SDS, Skiplist, Ziplist)

• SDS (Simple Dynamic Strings): Binary-safe, $O(1)$ length check.
• Skiplists: Used in ZSets for $O(log N)$ range queries.
• Ziplists: Compressed contiguous memory for small lists/hashes.

Memory Behavior

Small data is "Promoted" from packed structures (Ziplists) to sparse ones (Hashtables) as it grows. This is Encoding Switching.

What we Simplified

In Node.js, we rely on V8's Garbage Collector. In Redis, memory is manually managed via jemalloc, ensuring almost zero fragmentation.

4. Algorithms: LRU Eviction & TTL

Algorithms (LRU, LFU)

• Approximated LRU: Uses random sampling to find "cold" data globally.
• LFU (Least Frequently Used): Tracks counters in the robj to evict data that isn't accessed often over time.

Bottlenecks & Backpressure

If memory is full and eviction can't keep up with new writes, Redis enters a "High Latency" state as every write triggers a synchronous (blocking) eviction cycle.

What Redis does differently

Redis uses Lazy Freeing (Async Deletion) to delete massive objects in the background, so the main event loop never freezes.

5. Persistence (AOF / RDB)

Internal Architecture

AOF is a sequential log; RDB is a binary snapshot.

Why Redis is Optimized

Redis uses the fork() syscall. This allows the OS to perform a "Copy-on-Write" snapshot, letting the parent process stay active while the child writes 100GB to disk in the background.

Edge Cases & Failure Scenarios

If the disk is slow, fsync can cause Disk Backpressure, where the main thread blocks waiting for the hardware, effectively killing database performance.

The Core Mastery Question

Q: Why is Redis faster than a multi-threaded database like Postgres for KV workloads? A: Avoidance of Lock Contention. Multi-threaded databases spend up to 40% of their CPU cycles just waiting for mutexes (locks) to ensure two threads don't corrupt the data. Redis removes the locks entirely by being single-threaded, and uses I/O Multiplexing to ensure that single thread is never idle.