Bird
Raised Fist0

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

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
Clients

Send read request

Client requests data key 'user:123' from cache

Protocol:Web Request (GET)
BeforeClient has data key 'user:123' unknown locally
AfterRead request sent to Cache Layer (Redis)
Cache Layer (Redis)

Cache miss detected

Redis GET returns null for 'user:123'

Protocol:Redis GET
Before'user:123' not present in Redis cache
AfterCache Loader Service invoked to fetch from Read DB
Cache Loader Service

Load data from Read DB

Queries Read DB (Cassandra) for 'user:123'

Protocol:CQL Query
BeforeCache Loader Service has no data for 'user:123'
AfterData for 'user:123' retrieved from Read DB
Cache Layer (Redis)

Populate cache

Cache Loader Service writes 'user:123' data into Redis

Protocol:Redis SET
Before'user:123' missing in cache
After'user:123' cached in Redis for future reads
Clients

Send write request

Client updates data key 'user:123' with new value

Protocol:Web Request (SET)
BeforeClient has updated data for 'user:123'
AfterWrite request sent to Cache Layer (Redis)
Cache Layer (Redis)

Write-Through: update cache and DB synchronously

Redis SET updates cache and synchronously calls Write DB

Protocol:Redis SET + CQL Write
Before'user:123' cached with old value
After'user:123' cache updated and Write DB updated synchronously
Write-Behind Worker

Asynchronously write cache updates to Write DB

Worker reads updated cache keys and writes to Write DB

Protocol:CQL Write
BeforeCache updated but Write DB may be stale
AfterWrite DB eventually consistent with cache
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│    Clients    │
└───────┬───────┘
        │ Web Request (GET/SET)
        ▼
┌───────────────┐
│ Cache Layer   │
│   (Redis)     │
└───────┬───────┘
        │ Redis GET / Redis SET
        ▼
┌───────────────┐
│ Cache Loader  │
│   Service     │
└───────┬───────┘
        │ CQL Query (Read DB)
        ▼
┌───────────────────────┐
│ Read DB (Cassandra)   │
└───────────────────────┘

        ▲
        │
        │
┌───────────────┐
│Write-Behind   │
│ Worker        │
└───────┬───────┘
        │ CQL Write (Write DB)
        ▼
┌────────────────────────┐
│ Write DB (Cassandra)   │
└────────────────────────┘
Design Rationale

This architecture diagram illustrates four caching patterns: Cache Aside, Read-Through, Write-Through, and Write-Behind. Clients first query the Cache Layer (Redis). On a cache miss, the Cache Loader Service fetches data from the Read Database (Cassandra) and populates the cache (Read-Through). For writes, the Cache Layer can synchronously update both cache and Write Database (Write-Through), or update cache first and defer database writes to the Write-Behind Worker asynchronously. The separation of Read and Write Databases highlights different read and write paths. This design balances latency and consistency trade-offs by choosing appropriate caching strategies per use case.

Primary Focus

✓

Practice

(1/5)
1. In the request flow, at Step 4 the CDN edge server checks its cache for the requested asset. What happens if the asset is not found in the cache?
easy
A. The CDN edge server returns a 404 error immediately to the client
B. The CDN edge server redirects the client to the origin server URL
C. The CDN edge server serves a stale cached version without contacting origin
D. The CDN edge server forwards the request to the origin server to fetch the asset

Solution

  1. Step 1: Trace CDN cache miss handling at Step 4

    When the asset is missing in the edge cache, the CDN must retrieve it from the origin server.

  2. Step 2: Confirm CDN forwards request to origin server for fresh content

    The CDN edge server acts as a proxy, fetching the asset from origin to serve the client.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Cache miss triggers origin fetch, not error or redirect [check]
Hint: Cache miss -> fetch from origin server, not error or redirect [OK]
Common Mistakes:
2. For a recommendation engine requiring fast traversal of user-item relationships with frequent updates, which architecture is best suited?
medium
A. Use a key-value store with denormalized recommendation lists per user
B. Use a relational database with complex JOIN queries for recommendations
C. Use a batch-processing pipeline over a document store to precompute recommendations
D. Use an in-memory graph database with eventual consistency for fast traversals

Solution

  1. Step 1: Analyze requirement

    Fast traversal with frequent updates demands low-latency graph traversals and quick writes.

  2. Step 2: Evaluate architectures

    Relational DBs have high JOIN cost; batch pipelines add latency; key-value stores lack flexible traversal.

  3. Step 3: Choose architecture

    In-memory graph DBs with eventual consistency balance fast traversals and update throughput.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    In-memory graph DBs optimize traversal speed and handle frequent updates well [check]
Hint: In-memory graph DBs balance speed and updates best [check]
Common Mistakes:
3. If the token assignment metadata is lost or corrupted in a consistent hashing system with virtual nodes, what exactly breaks?
medium
A. Only new nodes fail to receive keys, existing nodes continue serving correctly
B. Requests cannot be routed to correct nodes, causing key lookups to fail or go to wrong nodes
C. The system continues routing keys correctly but load balancing is uneven
D. The system falls back to modulo hashing automatically without data loss

Solution

  1. Step 1: Understand role of token assignment metadata

    Token metadata maps virtual nodes to physical nodes; losing it breaks new node integration.

  2. Step 2: Trace failure impact

    Existing nodes continue serving keys assigned before loss; new nodes cannot be assigned tokens properly.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Token metadata loss blocks new node assignment; existing nodes unaffected [check]
Hint: Token metadata loss blocks new nodes, existing nodes serve [check]
Common Mistakes:
4. For a high-read, low-write system, which caching strategy best balances freshness and performance?
medium
A. Use write-through cache to update cache synchronously on every write
B. Disable caching and rely on database read replicas for freshness
C. Use write-back cache to batch writes and update cache asynchronously
D. Use cache-aside pattern where application loads cache on demand and invalidates on writes

Solution

  1. Step 1: Analyze write frequency and freshness needs

    High-read, low-write favors lazy loading and invalidation to avoid cache update overhead.

  2. Step 2: Evaluate caching strategies

    Write-through adds write latency; write-back risks stale data; cache-aside balances freshness and performance.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Cache-aside suits high-read, low-write with freshness [check]
Hint: Cache-aside balances freshness and performance [check]
Common Mistakes:
5. For a time-series IoT data ingestion system requiring high write throughput and efficient range queries by device and time, which data modeling approach is best?
medium
A. Partition by timestamp and cluster by device ID
B. Partition by device ID and cluster by timestamp within each partition
C. Use a single partition key for all devices and cluster by timestamp
D. Use a relational database with indexes on device and timestamp

Solution

  1. Step 1: Analyze query and write patterns

    Queries filter by device and time ranges; writes are high volume per device.

  2. Step 2: Evaluate partitioning strategies

    Partitioning by device ID localizes writes and queries; clustering by timestamp supports efficient range scans. Single partition key causes hotspots; partitioning by timestamp scatters device data, hurting queries; relational DBs can't handle high write scale.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Partition by device ID + cluster by timestamp -> balanced writes and efficient queries [check]
Hint: Partition by device, cluster by time for time-series data [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