Understanding Hotspot Key Issues and Alibaba Cloud Database Solutions

Hotspot key problems arise mainly from two situations: massive read‑heavy traffic such as flash‑sale items, trending news, or live streams that generate far more consumption requests than production data, and request concentration on a single server where a specific key exceeds the server’s performance limits.

The consequences include traffic concentrating to the point of saturating physical network interfaces, overwhelming cache shard services, and ultimately causing database overload that can trigger a cascading service failure (snowball effect).

Common mitigation approaches focus on client‑side or server‑side modifications, such as server‑side LRU caching, using external caches like Memcache or Redis, and local caching. These methods suffer from issues like cache invalidation, memory waste, dirty reads, limited cache capacity, and difficulty identifying hotspot keys.

Alibaba Cloud proposes a read‑write separation architecture: an SLB layer for load balancing, a Proxy layer that routes write requests to a Master node and read requests to ReadOnly nodes, with Slave nodes providing high availability. This design distributes read traffic, allows horizontal scaling of read‑only nodes, and transparently handles hotspot reads.

Another solution adds a Proxy‑based hotspot data layer: the Proxy maintains a local LRU cache for detected hotspot keys, while backend DB nodes periodically compute hotspot statistics. The Proxy serves cached hotspot data directly to clients, reducing load on Redis and the primary database, and the approach is fully transparent to clients.

Comparative analysis shows that Alibaba Cloud’s solutions offer greater scalability, cost efficiency, and client transparency than traditional methods, with read‑write separation handling larger volumes of hotspot data and the Proxy approach providing a lightweight, extensible alternative.