Mastering Server‑Side Caching: Design Patterns, Redis Tips, and Best Practices

1. Service‑Side Data Cache

In distributed web applications, high concurrency and internal decoupling rely heavily on caching and queuing; cache plays a role similar to CPU caches in hardware. Even modest‑size internet projects reserve cache designs early, but the choice between local and distributed caches introduces technical costs that must be carefully weighed.

Local cache refers to in‑process storage, while distributed cache resides on one or more external servers. Most real‑world systems use a hybrid approach. Understanding the essence of caching is more important than memorising classification schemes.

2. Cache Database Structure Design Details

2.1 Instance

Separate public data and business‑specific data into different Redis instances. A single instance can use multiple logical databases (DB) for isolation, but in a Redis Cluster the default is a single DB; you may still partition by project size and reserve instances for future stages.

If persistence (AOF/RDB) is enabled, high write loads can heavily contend for CPU and disk I/O, so plan persistence strategy and consider sharding instances when necessary.

2.2 Cache “Table”

Although Redis does not have traditional tables, key‑value pairs can be organised to mimic table structures. For a login‑server table with fields name, sign, addr, you might store:

{ "key": "server:name", "value": "xxxx" }
{ "key": "server:sign", "value": "yyyy" }
{ "key": "server:addr", "value": "zzzz" }

Select appropriate Redis data types (String, Hash, etc.) based on data relationships and column count.

2.3 Cache Key

Keep keys short yet descriptive. Use a common prefix for keys belonging to the same business module to simplify lookup and statistics, e.g., ul:server:a, ul:server:b. A unique global prefix per system is optional.

2.4 Cache Value

Value size should be as small as possible; large values (e.g., >10 MiB) degrade Redis response time and increase network I/O. Consider splitting hot and cold data when values become too big.

2.5 Persistence

Persistence decouples memory from disk, allowing fast recovery after restart. Redis offers AOF, RDB, and a hybrid mode. Enable both AOF and RDB in most high‑concurrency scenarios, but you may disable persistence for low‑traffic modules to save resources.

2.6 Eviction

Unbounded growth leads to memory spikes and latency spikes. Set a maximum memory limit and choose an eviction policy. Common choices are allkeys‑lru or volatile‑lru for power‑law access patterns, or no‑eviction for log‑type caches that rely on explicit expiration.

3. Basic CRUD Operations for First‑Level Cache

3.1 Create

When inserting a cache entry, always set an expiration time and randomise TTL to avoid cache avalanche. For bulk caching of 100 000 items with a base TTL of 2 hours, add a random offset (0‑1000 seconds) to each entry.

3.2 Update

Updating a cached item may require resetting its TTL. In many cases, deleting the key and letting the upstream system repopulate it is safer, especially when synchronising multiple caches.

3.3 Read

Prefer exact‑key lookups; avoid wildcard patterns that trigger full scans. If you must iterate over many keys, use SCAN with pagination instead of KEYS to limit blocking and memory pressure.

3.4 Delete / Clear

Cache removal can be immediate deletion or setting a short expiration. Bulk flushes ( FLUSHDB, FLUSHALL) block the server and should be used with caution.

3.5 Locking

Distributed locks are an auxiliary feature, not a core cache function; Redis provides atomic primitives for simple lock scenarios.

3.6 Publish‑Subscribe

Pub/Sub belongs to message‑queue territory. Although Redis supports it, misuse can create tight coupling and performance bottlenecks. Prefer dedicated MQ solutions such as RabbitMQ or Kafka for reliable messaging.

The article ends here, with a promise to expand on related topics in future posts.