Why Redis Is So Fast and How to Avoid Common Caching Pitfalls

Redis Overview

Redis is an open‑source, high‑performance, in‑memory key‑value store written in C. It can be used as a database, cache, or message broker and belongs to the NoSQL family.

Key Features

Excellent performance because data resides in memory, supporting up to 100 k QPS.

Single‑threaded, single‑process model with I/O multiplexing (thread‑safe).

Can serve as a distributed lock.

Supports ten data types.

Provides persistence.

Message publish/subscribe capabilities.

Data Types

Commonly used data types and their typical scenarios are shown in the diagram below.

Caching with Redis

Redis is often used for caching in Spring Boot, either via RedisTemplate directly or through Spring Cache annotations.

Cache‑related Problems

1. Data Consistency

In distributed systems, cache‑database consistency is hard; strong consistency usually means avoiding cache, otherwise use strategies such as cache‑update after DB write or retry mechanisms.

2. Cache Avalanche

When a cache node fails, all requests fall back to the database, potentially overwhelming it. Solutions include high‑availability setups (master‑slave + Sentinel or cluster), rate limiting, and graceful degradation.

3. Cache Penetration

Requests for nonexistent keys bypass cache and hit the DB. Mitigations: request validation, Bloom filter, or storing a placeholder key in Redis.

4. Cache Breakdown

Hot keys that expire simultaneously cause a surge of DB traffic. Solutions depend on data change frequency: never expire hot data, use distributed locks, or proactively refresh cache before expiration.

Why Redis Is So Fast

Hash‑map‑like O(1) lookups, all operations are in‑memory.

Simple key‑value data model.

Single‑threaded design eliminates lock contention.

Non‑blocking I/O with multiplexing.

Eviction Policies

volatile* – evict only expired keys.

allkeys* – evict from the whole keyspace.

LRU – least recently used.

LFU – least frequently used.

Triggered when memory usage reaches the configured threshold.

Persistence

Two persistence mechanisms: RDB: snapshot of memory to a dump file at intervals. AOF: append every write command to a log file; default is RDB, but both can be enabled with AOF taking precedence on restart.

Replication

Slave nodes execute SLAVEOF masterIP masterPort, sync data from the master, and continuously receive write commands to keep data consistent.

Sentinel Mode

Provides monitoring, notification, automatic failover, and configuration provisioning, eliminating manual intervention when the master fails.