Design and Implementation of an Outbox Redis Local Cache to Reduce Read Amplification

The article analyzes the high‑CPU pressure on the outbox Redis cluster caused by feed‑stream read amplification during hot events, proposes a local‑cache solution for hot UPs, details its design, consistency mechanisms, and shows that the optimization cuts peak CPU usage by over 40% while achieving more than 55% cache hit rate.

Architect
Architect
Architect
Design and Implementation of an Outbox Redis Local Cache to Reduce Read Amplification

During high‑traffic events the dynamic feed service experiences a 2‑3× surge in feed‑stream requests, causing the outbox Redis cluster to exceed 95% CPU usage on many instances, leading to timeouts and degraded user experience.

The root cause is read amplification from the "pull" side of the outbox: each fan pulls a page of feeds from many upstream users' outbox, resulting in hundreds to thousands of times more reads than writes.

Two mitigation paths were considered: (1) increase the threshold for pushing content to users' inboxes, which would reduce outbox reads but dramatically increase inbox write pressure and storage; (2) introduce a local cache for hot upstream users (UPs) to serve recent outbox entries directly from the outbox service instance.

The chosen solution caches recent outbox entries of hot UPs in the outbox service’s local memory. Hot UPs are identified by a fan‑count threshold derived from historical traffic analysis; their latest dynamic lists are pre‑fetched from Redis and stored locally.

When an outbox instance starts, it loads the full hot‑UP list from Redis and pulls the latest entries for each. Subsequent updates are handled via a "change broadcast + asynchronous rebuild" mechanism: a change event for a cached UP triggers all instances to asynchronously refresh the local cache, avoiding a thundering‑herd of simultaneous expirations.

Consistency is ensured through two checks: (a) on‑change verification that the checksum of the local cache matches the checksum stored in Redis, and (b) a daily periodic audit comparing all cached UPs across instances with Redis; mismatches trigger another broadcast‑based rebuild.

After deployment, the local cache achieved a hit rate above 55%, reduced the outbox Redis peak load by roughly 44% during weekend peaks, and lowered the per‑instance CPU peak by 37.2%.

Future work includes extending caching to hot video and series UPs and adding a real‑time hot‑key discovery mechanism for previously uncached UPs that may become hot under specific scenarios.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Performance OptimizationcacheScalabilityOutbox
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.