Bird
Raised Fist0

Cache Aside vs Read-Through vs Write-Through vs Write-Behind

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Cache Aside vs Read-Through vs Write-Through vs Write-Behind
Comparing caching patterns for read/write consistency, latency, and throughput at scale
mediumCachingFreq: common
⚙️
Functional Requirements
  • Serve low-latency read requests with cache hits whenever possible
  • Ensure data consistency between cache and backing store for reads and writes
  • Support high write throughput with minimal write amplification
  • Handle cache misses gracefully with minimal impact on user experience
  • Support TTL-based cache invalidation and stale data eviction
  • Allow configurable consistency guarantees (strong vs eventual) per use case
📊
Non-Functional Requirements
  • Support 2 billion daily active users generating 40 reads and 10 writes per user per day
  • Achieve 99.99% availability for read and write operations
  • Maintain 100ms P99 latency for cache hits and 200ms P99 for cache misses
  • Handle peak write QPS of up to 1 million writes per second
  • Ensure data durability with replication factor of 3 and retention of 30 days
❓
Clarifying Questions to Ask
  • What is the acceptable staleness window for cached data?
  • Are writes latency-sensitive or can they be eventually consistent?
  • What is the expected read-to-write ratio for the workload?
  • Is the cache shared across multiple services or per service?
  • What is the TTL or eviction policy for cached entries?
  • Are there any constraints on cache size or memory footprint?
Out of Scope
✗ Designing the underlying database schema or data model beyond caching
✗ Authentication, authorization, and security mechanisms
✗ Detailed network infrastructure or CDN design
✗ Client-side caching or offline mode support
📌
Assumptions
  • 2 billion DAU
  • 40 reads per user per day
  • 10 writes per user per day
  • Average data size per read/write: 100 bytes
⚡
QPS Calculation
write qps2B × 10 / 86400 ≈ 231,481 writes/sec
peak write qpsAssuming 4x peak factor: 231,481 × 4 ≈ 925,925 writes/sec
read qps2B × 40 / 86400 ≈ 925,925 reads/sec
💾
Storage Estimate
daily storage gb(2B × (10 + 40) × 100 bytes) / (1024^3) ≈ 23.28 TB/day
retention days30
total storage with replication gb23.28 TB × 30 days × 3 replicas ≈ 2.1 PB
🖥️
Server Estimate
cache serversAssuming Redis instance handles 50K QPS, need 19 servers for peak reads
db serversAssuming Cassandra node handles 50K writes/sec, need 19 nodes for peak writes
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |   Clients   |
          +------+------+
                 |
                 v
          +------+-------+
          |  Cache Layer |
          |  (Redis)     |
          +------+-------+
                 |
       +---------+----------+
       |                    |
       v                    v
 +-----+-----+        +-----+-----+
 | Write DB  |        | Read DB   |
 |(Cassandra)|        |(Cassandra)|
 +-----------+        +-----------+
🧩
Components
Clients
Issue read and write requests to the system
Why thisClients represent end-users or services generating workload
Why notN/A - clients are external actors
Cache Layer (Redis)
Serve low-latency reads and buffer writes depending on pattern
Why thisRedis supports TTL, sub-millisecond lookups, and atomic operations for cache consistency
Why notMemcached lacks persistence and advanced eviction policies needed for consistency
Write Database (Cassandra)
Durable storage for writes with high write throughput and replication
Why thisCassandra scales linearly for writes, supports tunable consistency, and multi-region replication
Why notPostgreSQL requires complex manual sharding at 925K writes/sec; B-tree writes don't scale linearly
Read Database (Cassandra)
Serve consistent reads when cache misses occur or for validation
Why thisSame as write DB for consistency and availability; read replicas optimize read throughput
Why notElasticsearch is optimized for search, not consistent key-value reads
Cache Loader Service
Fetch data from DB on cache miss for Read-Through and Cache Aside patterns
Why thisDecouples cache miss handling and prevents thundering herd by batching and rate limiting
Why notDirect DB calls from clients cause inconsistent caching and increased latency
Write-Behind Worker
Asynchronously flush writes from cache to DB in Write-Behind pattern
Why thisKafka-based queue enables reliable, ordered, and scalable write buffering
Why notSynchronous writes increase latency; direct DB writes block client
🔄
Data Flow
1
Client → Cache Layer
Read request
Cache hit returns data immediately with <100ms latency
2
Cache Layer → Cache Loader Service
Cache miss triggers loader
Loader fetches data from DB to populate cache
3
Cache Loader Service → Read Database
Fetch data on cache miss
Ensures consistent data read from durable store
4
Client → Cache Layer
Write request (Cache Aside or Write-Through)
Write updates cache and optionally DB synchronously
5
Cache Layer → Write-Behind Worker
Buffer writes asynchronously
Write-Behind pattern queues writes for eventual DB flush
6
Write-Behind Worker → Write Database
Flush writes from queue to DB
Ensures durability with eventual consistency

Practice

(1/5)
1. A distributed cache system must evenly distribute keys across nodes and gracefully handle node failures without massive key remapping. Which component or technique best addresses this requirement?
easy
A. Implementing consistent hashing with virtual nodes
B. Storing all keys in a single master node for centralized control
C. Using a simple modulo hash function on node count to assign keys
D. Using random key assignment to nodes without hashing

Solution

  1. Step 1: Understand key distribution needs

    Simple modulo hashing (Using a simple modulo hash function on node count to assign keys) causes massive remapping when nodes change, failing graceful scaling.

  2. Step 2: Evaluate consistent hashing benefits

    Consistent hashing with virtual nodes (Implementing consistent hashing with virtual nodes) minimizes remapping and balances load even with node failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consistent hashing with virtual nodes -> minimal key remapping on node changes [check]
Hint: Consistent hashing + virtual nodes minimize remap on node changes [OK]
Common Mistakes:
2. For an API Gateway that must support both REST and gRPC clients, which architecture best balances protocol support and transformation complexity?
medium
A. Use gRPC-only API Gateway and require REST clients to upgrade to gRPC
B. Use separate API Gateways for REST and gRPC, each optimized for its protocol
C. Use REST-only API Gateway and require gRPC clients to use a proxy converting gRPC to REST
D. Use a single API Gateway that performs protocol translation and transformation internally

Solution

  1. Step 1: Analyze protocol support requirements

    Supporting both REST and gRPC clients in one gateway reduces operational complexity and centralizes transformation logic.

  2. Step 2: Evaluate alternatives

    Use separate API Gateways for REST and gRPC, each optimized for its protocol increases deployment and maintenance overhead. Use REST-only API Gateway and require gRPC clients to use a proxy converting gRPC to REST adds latency and complexity on client side. Use gRPC-only API Gateway and require REST clients to upgrade to gRPC is impractical as REST clients are widespread.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Single gateway with protocol translation balances support and complexity [check]
Hint: One gateway handles both protocols with internal translation [check]
Common Mistakes:
3. For a high-traffic public API requiring both strong security and minimal latency, which TLS configuration trade-off is most appropriate?
medium
A. Use TLS 1.3 with ephemeral key exchange to enable forward secrecy and reduce handshake latency
B. Use self-signed certificates to avoid certificate chain overhead
C. Disable certificate validation to speed up connections
D. Use TLS 1.0 with RSA key exchange for compatibility

Solution

  1. Step 1: Evaluate TLS versions and key exchange

    TLS 1.3 supports ephemeral key exchange (ECDHE) which provides forward secrecy and reduces handshake round trips, lowering latency.

  2. Step 2: Eliminate other options

    Use TLS 1.0 with RSA key exchange for compatibility uses outdated TLS 1.0 and RSA key exchange lacking forward secrecy and higher latency. Disable certificate validation to speed up connections compromises security by disabling validation. Use self-signed certificates to avoid certificate chain overhead risks trust issues and is unsuitable for public APIs.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TLS 1.3 ephemeral keys -> forward secrecy + lower latency [check]
Hint: TLS 1.3 ephemeral keys = forward secrecy + low latency [check]
Common Mistakes:
4. At 10x traffic scale during a flash sale, which component is most likely to fail first and why?
hard
A. The relational database because it cannot handle 10x write throughput without sharding
B. The API Gateway because it maintains stateful user sessions and cannot horizontally scale easily
C. The cache layer because TTL expiration floods the database with cache misses
D. The inventory service because distributed locking causes contention and latency spikes

Solution

  1. Step 1: Identify stateful components under load

    API Gateway maintains user session state (e.g., WebSocket connections), which are sticky and stateful, limiting horizontal scaling.

  2. Step 2: Compare other components

    Relational DB (A) can be sharded; cache (C) TTL floods are mitigated by pre-warming; inventory locking (D) is optimized with partitioning. API Gateway statefulness causes connection limits and bottlenecks first.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    API Gateway stateful sessions limit horizontal scaling [check]
Hint: Stateful API Gateway limits scaling under 10x load [check]
Common Mistakes:
5. At 10x scale, which component in a distributed lock system using ZooKeeper is most likely to fail first and why?
hard
A. ZooKeeper ensemble leader, due to increased write load and session management overhead
B. Clients, because they cannot handle the increased lock acquisition requests
C. Network routers, because of increased traffic causing packet loss
D. Storage backend, because ephemeral nodes consume excessive disk space

Solution

  1. Step 1: Identify ZooKeeper leader role

    The leader handles all write requests and session heartbeats, becoming a bottleneck under high scale.

  2. Step 2: Evaluate other components

    Clients (A) can be scaled horizontally; network routers (C) are less likely the first bottleneck; ephemeral nodes (D) are lightweight and cleaned up automatically.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Leader bottleneck due to write and session overhead [check]
Hint: ZooKeeper leader handles all writes -> first bottleneck [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard