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 Caching Patterns
45 min · senior
senior

You are designing the caching layer for a 50 million daily active user (DAU) social media platform that serves personalized user feeds. The system must handle 100,000 QPS read requests and 20,000 QPS write requests with a P99 latency under 200ms. Data must be encrypted at rest and in transit due to privacy regulations. The cache must maintain strong consistency for user profile updates but can tolerate eventual consistency for feed content. Offline delivery of feed updates is required for mobile clients with intermittent connectivity.

Constraints
  • P99 latency under 200ms for read and write operations
  • Data encryption at rest and in transit (TLS + AES-256)
  • Strong consistency required for user profile data
  • Eventual consistency acceptable for feed content
  • Offline delivery support for mobile clients with intermittent connectivity
📋
Guided Steps
1/5
Step 1
Choosing the Caching Pattern for Reads
Which caching pattern would you choose for read operations to balance latency and consistency for user profile and feed data?
💡 Hint
Consider whether the cache should be populated on demand or proactively, and how cache misses affect latency.
Key Decision
Use Cache Aside pattern with Redis for feed content (eventual consistency) and Read-Through pattern with Memcached for user profiles (strong consistency).
Interviewer Expectation
Mid: Names Redis and Memcached for caching. Senior: Explains Cache Aside for feed due to eventual consistency tolerance and Read-Through for profiles to guarantee strong consistency and reduce stale reads.
⚠️Common Wrong Answer
Using only Cache Aside for all data - leads to stale reads for user profiles and inconsistent user experience.
Step 2
Choosing the Caching Pattern for Writes
How would you handle write operations to ensure data consistency and meet latency requirements?
💡 Hint
Think about synchronously updating cache vs asynchronously and the impact on write latency and data freshness.
Key Decision
Use Write-Through caching with Redis for user profile writes to ensure strong consistency and Write-Behind caching with Kafka-backed queue for feed content to optimize write latency and throughput.
Interviewer Expectation
Mid: Mentions Write-Through for consistency. Senior: Explains Write-Through for profiles to synchronously update cache and DB, and Write-Behind for feed to batch writes asynchronously, reducing write latency under 200ms.
⚠️Common Wrong Answer
Using Write-Behind for user profiles - causes stale reads and violates strong consistency SLA.
Step 3
Cache Invalidation and Refresh Strategy
How will you design cache invalidation or refresh to maintain consistency and freshness without overwhelming the database?
💡 Hint
Consider TTLs, explicit invalidation, and background refresh mechanisms.
Key Decision
Implement explicit cache invalidation on user profile updates with Redis key eviction and use TTL-based expiration with background refresh workers for feed content in Redis.
Interviewer Expectation
Mid: Describes TTL usage. Senior: Details explicit invalidation on writes for profiles to avoid stale data and background refresh with Redis streams for feed to balance freshness and DB load.
⚠️Common Wrong Answer
Relying solely on TTL expiration - causes stale data spikes and inconsistent user experience.
Step 4
Handling Encryption and Offline Delivery Constraints
How do you ensure data encryption and support offline delivery for mobile clients in your caching design?
💡 Hint
Think about encryption at rest/in transit and how cache data syncs with intermittent connectivity.
Key Decision
Use Redis with TLS for in-transit encryption and AES-256 encrypted data at rest; implement client-side local cache with conflict resolution and use Kafka for offline feed update delivery and replay.
Interviewer Expectation
Mid: Mentions TLS and encryption. Senior: Explains Redis TLS + AES-256 integration, client local cache for offline mode, and Kafka for durable offline feed update delivery with replay and ordering guarantees.
⚠️Common Wrong Answer
Ignoring encryption or offline delivery - leads to data breaches and poor UX for mobile users.
Step 5
API Design for Cache Interaction
Design three core API endpoints to support reading, writing, and cache invalidation/refresh operations in this caching system.
💡 Hint
Consider how clients interact with cache and database, and how cache consistency is maintained via APIs.
Key Decision
Define GET /user/{id} with cache read-through, POST /user/{id} with write-through cache update, and POST /cache/invalidate with explicit cache key invalidation using Redis commands.
Interviewer Expectation
Mid: Provides basic REST endpoints. Senior: Details cache interaction semantics, error handling, and how invalidation triggers cache refresh without DB overload.
⚠️Common Wrong Answer
Designing APIs without cache invalidation endpoint - leads to stale cache and inconsistent data.
🔌
API Design Challenge
Sketch 3 core API endpoints to support caching with these patterns: one for reading data, one for writing data, and one for cache invalidation or refresh.
Hints
  • How does the client request data and handle cache misses?
  • How does the client update data and ensure cache consistency?
  • How is cache invalidation or refresh triggered and handled?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Correct identification and justification of caching patterns per data type and consistency needs
  • Use of Redis with TLS and AES-256 for secure caching
  • Explicit cache invalidation strategy to maintain strong consistency for user profiles
  • Use of Kafka for asynchronous write-behind and offline delivery
  • API design covering read, write, and cache invalidation endpoints
Good to Have - 30%
  • Background refresh workers for feed cache TTL expiration
  • Client-side local cache design for offline support
  • Detailed latency and throughput estimations supporting design choices
Bonus - 10%
  • Discussion of failure modes and recovery strategies for cache and message queue
  • Trade-off analysis between cache consistency and latency under load
Anti-patterns to Avoid
Using Write-Behind caching for user profiles causes stale reads and violates strong consistency SLA, leading to inconsistent user experience.
Relying solely on TTL expiration for cache invalidation causes stale data spikes and inconsistent user experience due to delayed cache refresh.
Ignoring encryption at rest and in transit risks data breaches and violates privacy regulations.
Not providing explicit cache invalidation endpoints leads to stale cache and inconsistent data across the system.
HTTP polling at 50M DAU: 50 million reconnects per minute just to check for messages - collapses under load and degrades system performance.
✅
Model Answer
▼ Reveal

This design uses Redis and Memcached caching layers with specific caching patterns tailored to data consistency needs. User profiles require strong consistency and use Read-Through and Write-Through caching with Redis and Memcached, while feed content tolerates eventual consistency using Cache Aside and Write-Behind with Redis and Kafka. Security is ensured via TLS and AES-256 encryption. Offline delivery is supported with client-side local cache and Kafka for durable feed updates. Cache invalidation uses explicit eviction for profiles and TTL with background refresh for feeds. APIs provide read, write, and cache invalidation endpoints to maintain consistency and performance.

Key Decisions
  • Use Cache Aside pattern with Redis for feed content to allow eventual consistency and reduce DB load
  • Use Read-Through pattern with Memcached for user profiles to guarantee strong consistency and low latency reads
  • Use Write-Through caching with Redis for user profile writes to synchronously update cache and DB ensuring consistency
  • Use Write-Behind caching with Kafka-backed queue for feed content writes to batch and asynchronously update DB, optimizing write latency
  • Implement explicit cache invalidation on user profile updates using Redis key eviction to avoid stale reads
  • Use TTL-based expiration with background refresh workers for feed content to balance freshness and DB load
  • Encrypt data at rest with AES-256 and in transit with TLS for compliance
  • Support offline delivery with client-side local cache and Kafka for durable feed update delivery with replay and ordering guarantees
  • Design REST APIs with cache read-through, write-through, and explicit invalidation endpoints to maintain cache consistency
  • Redis with TLS and AES-256 encryption for caching user profiles and feed content to meet security constraints
  • Cache Aside pattern for feed content using Redis to tolerate eventual consistency and reduce DB load
  • Read-Through pattern with Memcached for user profiles to guarantee strong consistency and low latency reads
  • Write-Through caching with Redis for user profile writes to synchronously update cache and DB ensuring consistency
  • Write-Behind caching with Kafka-backed queue for feed content writes to batch and asynchronously update DB, optimizing write latency
  • Explicit cache invalidation on user profile updates using Redis key eviction to avoid stale reads
  • TTL-based expiration with background refresh workers for feed content to balance freshness and DB load
  • Client-side local cache with conflict resolution for offline delivery support on mobile devices
  • Kafka for durable offline feed update delivery with replay and ordering guarantees
  • REST API endpoints: GET /user/{id} (read-through), POST /user/{id} (write-through), POST /cache/invalidate (explicit invalidation)

Practice

(1/5)
1. For delivering real-time location updates to mobile clients, which approach is better considering intermittent mobile network connectivity and battery constraints?
medium
A. Use WebSocket connections with automatic reconnection and heartbeat pings
B. Use persistent gRPC streaming connections to push updates continuously
C. Use HTTP long polling to simulate real-time updates
D. Use periodic client polling every few seconds to fetch updates

Solution

  1. Step 1: Evaluate persistent connection options

    gRPC streaming is efficient but less supported on mobile platforms and can drain battery.

  2. Step 2: Compare WebSocket and polling

    WebSocket supports bidirectional communication with reconnection and heartbeats, balancing real-time and battery use better than polling.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    WebSocket balances real-time updates and mobile constraints [check]
Hint: WebSocket with reconnection beats gRPC streaming on mobile [check]
Common Mistakes:
2. If the Metadata Server crashes before acknowledging a file rename operation, what is the most likely failure observed by the client?
medium
A. Client's write operations to the file silently fail without notification
B. Client receives an error and the file remains under the old name with no partial rename
C. Client sees the file renamed but data blocks lost
D. Client sees the file under both old and new names due to partial metadata update

Solution

  1. Step 1: Understand rename operation atomicity

    Rename involves updating metadata entries; if crash occurs mid-update, partial state may persist.

  2. Step 2: Trace failure effect

    Partial metadata update can cause both old and new filenames to appear, confusing clients.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Partial metadata updates cause duplicate filenames visible to client [check]
Hint: Partial metadata update causes duplicate filenames visible [check]
Common Mistakes:
3. For a chat application requiring low latency message delivery but tolerating occasional message loss, which architecture best balances latency and throughput?
medium
A. Use a batch processing system that aggregates messages every 5 seconds
B. Use a synchronous request-response system with guaranteed delivery acknowledgments
C. Use an asynchronous message queue with at-least-once delivery and eventual consistency
D. Use a distributed cache with write-through persistence for all messages

Solution

  1. Step 1: Analyze latency vs throughput needs

    Batch processing adds latency but can increase throughput and tolerate some message loss.

  2. Step 2: Evaluate architectures

    Synchronous (A) increases latency; asynchronous queue (B) reduces latency but may cause duplicates; distributed cache (D) lacks delivery guarantees; batch (C) balances throughput with acceptable latency for some use cases.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Batching trades latency for throughput, tolerating some loss [check]
Hint: Batching trades latency for throughput and tolerates loss [check]
Common Mistakes:
4. At 10x scale, which component in the real-time location tracking system is most likely to fail first, and why?
hard
A. Geo-indexing database, because spatial queries become exponentially slower with more data
B. Kafka cluster, because partition count limits throughput and causes producer backpressure
C. Relational database, because write locks cause contention under high update rates
D. WebSocket servers, because maintaining millions of stateful connections exhausts memory and CPU

Solution

  1. Step 1: Analyze stateful connection bottleneck

    WebSocket servers hold persistent TCP connections consuming memory and CPU; scaling requires sharding connections.

  2. Step 2: Compare other components

    Kafka scales by adding partitions; geo-indexing scales with sharding; relational DB is less critical for real-time writes.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    WebSocket servers hit stateful connection limits first at scale [check]
Hint: Stateful WebSocket connections limit scaling first [check]
Common Mistakes:
5. At 10x scale, which component in a NoSQL cluster handling user sessions fails first and why?
hard
A. The load balancer because it cannot distribute requests evenly at scale
B. The session management layer because it maintains stateful connections that can't be sharded easily
C. The storage nodes because disk I/O saturates under high write volume
D. The network switches because they cannot handle increased traffic volume

Solution

  1. Step 1: Identify storage node bottlenecks at high write volume

    Disk I/O can saturate under 10x writes, limiting storage node throughput.

  2. Step 2: Compare other components' scalability

    Session management can shard state; load balancers and network switches scale with hardware upgrades.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Disk I/O saturation -> storage node bottleneck at 10x scale [check]
Hint: Disk I/O saturates first at 10x writes [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