Backend Performance Optimization: System Cache Architecture Design

Description
System cache architecture design involves planning the organizational structure, data flow strategies, and consistency schemes of multi-level caches in backend systems to ensure high-speed data access in high-concurrency scenarios. You need to master the collaboration principles between local and distributed caches, cache granularity control, the pros and cons of update strategies (such as Cache-Aside/Write-Through), and how to reduce latency and database pressure through layered caching.

Detailed Explanation

1. Core Value of Cache Architecture

   • Reduce Latency: Store hot data in faster access media (such as memory) to reduce direct reliance on slower storage (such as databases).
   • Alleviate Backend Pressure: Intercept a large number of repeated requests through caching to prevent the database from being overwhelmed by high-frequency queries.
   • Improve System Throughput: Memory read/write speeds far exceed those of disks; cache hits can significantly increase request processing efficiency.

2. Multi-Level Cache Layered Design

   • Local Cache (L1 Cache):
     • Storage Location: Within the application process memory (e.g., HashMap, Guava Cache).
     • Advantages: Zero network overhead, extremely fast access speed.
     • Disadvantages: Data inconsistency (caches are independent across multiple instances), limited capacity.
     • Applicable Scenarios: Rarely changed data (e.g., configuration items), frequently accessed hot keys in a short period.
   • Distributed Cache (L2 Cache):
     • Storage Location: Independent clusters (e.g., Redis, Memcached).
     • Advantages: Data is shared across instances, capacity is scalable.
     • Disadvantages: Network latency (typically 1-5ms).
   • Layered Collaboration Process:

     Request → First check local cache → If missed → Check distributed cache → If missed → Check database
               ↓ If hit                    ↓ If hit
             Return directly           Return and backfill local cache
     

3. Cache Granularity Control Strategies

   • Full Cache: Cache complete objects (e.g., JSON or serialized data), suitable for small objects.
   • Partial Cache: Cache only frequently accessed fields (e.g., product name rather than details) to reduce memory usage.
   • Layered Cache:
     • Example: Basic information (name, price) of a product page is cached locally, while large fields like detailed descriptions are cached in Redis.
     • Advantage: Allocate storage locations based on access frequency to balance speed and resource costs.

4. Comparison of Cache Update Strategies

   • Cache-Aside (Lazy Loading):
     • Read Flow: Check cache → If missed, read database → Backfill cache.
     • Write Flow: Update database → Delete cache (instead of updating to avoid dirty data caused by concurrent writes).
     • Advantages: Simple and controllable, cache only stores data actually accessed.
     • Disadvantages: Initial requests inevitably penetrate to the database.
   • Write-Through:
     • Write Flow: Simultaneously update cache and database (requires transaction guarantees for consistency).
     • Advantages: Cache is always up-to-date, high read performance.
     • Disadvantages: Increased write latency, may cache a large amount of cold data.
   • Write-Behind (Write-Back):
     • Write Flow: Update cache first, asynchronously batch-write to the database.
     • Advantages: Extremely fast write operations, suitable for write-heavy, read-light scenarios.
     • Risks: Data loss risk (data not persisted if cache crashes).

5. Consistency Guarantee and Fault Tolerance

   • Delayed Double Deletion:
     • Scenario: Resolve dirty data caused by cache deletion failure in Cache-Aside when "update database first, then delete cache."
     • Operation: Update database → Delete cache → Delay for a few hundred milliseconds → Delete cache again.
   • TTL Fallback:
     • Set TTL (e.g., 30 minutes) for all cache keys. Even if updates fail, data will eventually be rebuilt through the expiration mechanism.
   • Hot Key Reconstruction Optimization:
     • Problem: A large number of requests flood the database the moment the cache expires.
     • Solution: Use mutual exclusion locks (e.g., Redis SETNX) to allow only one thread to rebuild the cache, while other threads wait.

6. Practical Case: E-commerce Product Detail Page Cache Architecture

   • Layered Design:
     • L1 (Local): Basic product information (expires in 10 minutes), using LRU eviction policy.
     • L2 (Redis): Product detail HTML fragments (expires in 30 minutes), stored in clustered shards.
   • Update Strategy:
     • When price changes: Asynchronously notify nodes to invalidate local cache; update Redis cache as needed.
     • When inventory changes: Directly update the database and delete Redis inventory cache (to ensure real-time accuracy).
   • Fallback Plan:
     • When Redis fails: Use circuit breakers to directly read local cache + database, returning downgraded data (e.g., default inventory).

Summary
An excellent cache architecture requires balancing performance, consistency, and complexity:

• Multi-level caches should be layered based on data hotness to avoid storing too much cold data in the L1 cache.
• The choice of update strategy depends on the business scenario (e.g., Cache-Aside for read-heavy, write-light scenarios; Write-Behind for write-heavy scenarios).
• Always set TTL and fallback strategies to prevent system avalanches caused by cache failures.