Hot Reads vs. Hot Writes

📋 Overview

"Hotness" in a system refers to disproportionate traffic directed at specific data. Distinguishing between Hot Reads (millions reading the same data) and Hot Writes (millions updating the same data) is crucial because the architectural solutions for each are fundamentally different. Failing to address either leads to hotspots, lock contention, and system instability.

---

🏗️ Core Principles & Characteristics

• Hot Reads (Read Hotspot):
  • Scenario: A viral tweet, a breaking news article, or a popular product page.
  • Impact: High bandwidth usage and CPU load on the cache/database node.
  • Nature: Usually easier to solve because data is immutable or changes slowly.
• Hot Writes (Write Hotspot):
  • Scenario: A "Like" counter on a viral post, a live auction bid, or a global inventory count during a flash sale.
  • Impact: Row-level locking, high I/O wait, and transaction failures due to contention.
  • Nature: Difficult to solve because it requires maintaining strict data consistency.

---

⚖️ Trade-offs: Pros & Cons

• Solving Hot Reads:
  • Strategy: Multi-layer caching and replication.
  • Trade-off: Data might be slightly stale (Eventual Consistency).
• Solving Hot Writes:
  • Strategy: Write-sharding, batching, or CRDTs.
  • Trade-off: High complexity in merging data; potentially sacrificing immediate read accuracy for write availability.

---

🌍 Real-World Implementation

• Hot Read Solution (Celebrity Profile): Use a CDN or a local L1 cache on the web server so the request never even reaches the main Redis cluster.
• Hot Write Solution (Like Counter):
  1. Distributed Counters: Split the counter into 100 "slots" (counter_1, counter_2...).
  2. Each write goes to a random slot.
  3. Total count = SUM(all slots).
• Messaging: Kafka partitions help distribute write load across different brokers based on a shard key.

---

💡 Interview "Gotchas" & Tips

• The "Thundering Herd" Problem: When a hot read key expires from the cache, all millions of users hit the DB at once. Solution: Cache Locking (Mutant) or Soft TTL (background refresh).
• Atomic Operations: Mention that INCR in Redis or UPDATE ... SET count = count + 1 in SQL is atomic but still hits a lock. Sharding the row is the only way to scale further.

---

📐 Suggested Architecture Primitives

• CDN / Edge Cache: For global Hot Reads.
• Write-Back Cache: Buffering writes in memory before flushing to DB.
• Shared-Nothing Architecture: Partitioning data so no two writes hit the same lock.
• Redis Clusters: With read-replicas for scaling read-heavy hotspots.