Write-Through vs Write-Back Cache: Memory Management Deep Dive

Introduction and Core Concepts

When comparing write-through vs write-back cache, we are examining two fundamentally different philosophies for handling data consistency between a fast, volatile cache and a slower, persistent backing store. Every modern computing system — from CPU L1 caches to distributed Redis clusters and browser storage — must answer a critical question: when data is modified in the cache, when should that modification be propagated to the main memory, disk, or database?

The answer defines the system's performance profile, fault tolerance, and consistency guarantees. A cache sits between the processor or application and the primary storage layer. Its purpose is to accelerate access by serving frequently used data from high-speed memory such as SRAM, DRAM, or in-memory data structures. However, this acceleration introduces a coherence problem. If the cached copy diverges from the backing store, which copy is authoritative? How long can divergence persist? What happens if power is lost before synchronization?

Write-through and write-back are the two dominant write policies that resolve this dilemma. In a write-through cache, every write operation is synchronously applied to both the cache and the backing store. The operation is only considered complete after both layers acknowledge success. This guarantees strong consistency but incurs a latency penalty on every write. In contrast, a write-back cache, also called write-behind, acknowledges the write as soon as the cache is updated and defers the backing store update until later — typically when the cache block is evicted or during a periodic flush. This approach dramatically reduces write latency and backing store traffic, but introduces complexity around dirty data management and crash recovery.

Understanding write-through vs write-back cache is essential for system designers because the choice directly impacts throughput, durability, and complexity. There is no universally superior policy. Financial ledgers prioritize durability over speed, while CPU caches and high-throughput web caches prioritize speed and coalesce writes. This deep dive explores the mechanisms, trade-offs, implementations, and practical decision framework for choosing between them.

How It Works

Write-Through Mechanism

In a write-through architecture, the data path is simple and deterministic. When an application issues a write for key K with value V, the cache controller first updates the cache line for K. It then immediately forwards the same write to the backing store. The client receives a success response only after both operations complete. If either fails, the entire operation is considered failed, and error handling must ensure both layers remain consistent. This two-phase commit on every write ensures the backing store is never stale.

Reads in a write-through system are straightforward. On a cache hit, data is returned directly from the cache with minimal latency. On a cache miss, data is fetched from the backing store, populated into the cache, and then returned. Because writes always keep the backing store current, a read miss can safely fetch from the backing store without worrying about dirty blocks that exist only in cache. This simplicity makes invalidation and coherence protocols easier to reason about, especially in multi-core or distributed environments where multiple caches may hold copies of the same data.

The primary cost is write latency and bandwidth amplification. Every logical write generates two physical writes, doubling the load on the backing store. For write-heavy workloads, this can saturate disk I/O or database throughput and negate much of the caching benefit. To mitigate this, some systems implement a write buffer that coalesces consecutive writes to the same block before flushing, but strictly speaking, a pure write-through policy does not coalesce — it propagates immediately.

Write-Back Mechanism and Dirty Bits

Write-back decouples cache updates from backing store updates to optimize for speed. When a write occurs, the cache controller updates the cached copy and marks the corresponding cache line as dirty using a dedicated dirty bit. A dirty line indicates that the cached value is newer than the backing store and must be flushed before eviction. Clean lines, where cache and backing store are synchronized, can be evicted silently without any I/O.

The backing store is updated lazily under three conditions: eviction of a dirty block due to capacity pressure, an explicit flush or sync command from the application, or a periodic background write-behind thread that scans for dirty blocks and writes them in batches. This batching is where write-back gains its efficiency. If an application updates the same key 100 times in rapid succession, a write-through cache performs 100 backing store writes, while a write-back cache may perform only one — the final value at eviction time.

This efficiency comes with significant complexity. The system must track dirty state accurately, handle power failures or crashes that could lose dirty data, and implement coherence protocols to ensure other readers do not see stale data from the backing store. Most write-back implementations pair the cache with a write-ahead log, battery-backed memory, or non-volatile RAM to guarantee durability despite deferred writes. Without such mechanisms, a crash can cause permanent data loss for all dirty blocks that had not yet been flushed.

Coherence and Consistency Implications

The choice between write-through vs write-back cache also affects memory consistency models. Write-through provides strong consistency by default because the backing store is always up to date. Any other component reading from the backing store will see the latest value. Write-back provides eventual consistency between cache and backing store, with a window of vulnerability where the backing store is stale. In multiprocessor systems, this requires cache coherence protocols like MESI, where dirty lines in one core's private cache must be snooped or invalidated before another core can read the backing store.

Implementation

Implementing both policies in Python clarifies their operational differences. The examples below simulate a cache fronting a slow backing store represented by a dictionary with artificial latency. The cache supports get and put operations with LRU eviction. Note how the write path diverges completely between the two policies while the read path remains similar.

import time
from collections import OrderedDict

class SlowBackingStore:
    """Simulates a slow database or disk."""
    def __init__(self):
        self.data = {}
        self.write_count = 0

    def read(self, key):
        # Simulate disk latency
        time.sleep(0.01)
        return self.data.get(key)

    def write(self, key, value):
        time.sleep(0.01)
        self.data[key] = value
        self.write_count += 1

class WriteThroughCache:
    """Write-through: every put writes to both cache and store synchronously."""
    def __init__(self, capacity, store):
        self.capacity = capacity
        self.store = store
        self.cache = OrderedDict()  # LRU via OrderedDict

    def get(self, key):
        if key in self.cache:
            # Cache hit: move to end (most recently used)
            self.cache.move_to_end(key)
            return self.cache[key]
        # Cache miss: fetch from backing store
        value = self.store.read(key)
        if value is not None:
            self.put(key, value, is_write_through_fetch=True)
        return value

    def put(self, key, value, is_write_through_fetch=False):
        # Always write to backing store first (or simultaneously)
        # For fetch-induced puts, we avoid double-writing if already in store
        if not is_write_through_fetch:
            self.store.write(key, value)

        # Update cache with LRU eviction
        if key in self.cache:
            self.cache.move_to_end(key)
        self.cache[key] = value
        if len(self.cache) > self.capacity:
            self.cache.popitem(last=False)  # Evict LRU, no dirty check needed

    def stats(self):
        return {"cache_size": len(self.cache), "store_writes": self.store.write_count}

class WriteBackCache:
    """Write-back: writes are cached and marked dirty, flushed on eviction."""
    def __init__(self, capacity, store):
        self.capacity = capacity
        self.store = store
        self.cache = OrderedDict()  # key -> value
        self.dirty = set()  # set of keys with unsynced changes
        self.hits = 0
        self.misses = 0

    def get(self, key):
        if key in self.cache:
            self.hits += 1
            self.cache.move_to_end(key)
            return self.cache[key]
        self.misses += 1
        # Cache miss: fetch from store
        value = self.store.read(key)
        if value is not None:
            # Make room if needed, flushing dirty victim first
            self._ensure_capacity()
            self.cache[key] = value
            # Fetched data is clean (in sync with store)
            if key in self.dirty:
                self.dirty.remove(key)
        return value

    def put(self, key, value):
        # Write to cache only, mark dirty
        if key in self.cache:
            self.cache.move_to_end(key)
        else:
            self._ensure_capacity()
        self.cache[key] = value
        self.dirty.add(key)  # Mark as needing flush
        # No store write here - deferred!

    def _ensure_capacity(self):
        if len(self.cache) < self.capacity:
            return
        # Evict LRU entry
        evict_key, evict_value = self.cache.popitem(last=False)
        if evict_key in self.dirty:
            # Flush dirty block to backing store
            self.store.write(evict_key, evict_value)
            self.dirty.remove(evict_key)
        # Clean blocks are just dropped

    def flush(self):
        """Force write all dirty blocks to backing store."""
        for key in list(self.dirty):
            self.store.write(key, self.cache[key])
        self.dirty.clear()

    def flush_key(self, key):
        """Flush a single key if dirty."""
        if key in self.dirty:
            self.store.write(key, self.cache[key])
            self.dirty.remove(key)

class WriteBackCacheWithWriteAllocate:
    """
    Write-back with write-allocate vs no-write-allocate handling.
    Demonstrates handling of write misses.
    """
    def __init__(self, capacity, store, write_allocate=True):
        self.capacity = capacity
        self.store = store
        self.write_allocate = write_allocate
        self.cache = OrderedDict()
        self.dirty = set()

    def put(self, key, value):
        hit = key in self.cache
        if hit:
            self.cache.move_to_end(key)
            self.cache[key] = value
            self.dirty.add(key)
        else:
            # Write miss policy
            if self.write_allocate:
                # Allocate line in cache, then write (common for write-back)
                if len(self.cache) >= self.capacity:
                    self._evict_lru()
                self.cache[key] = value
                self.dirty.add(key)
            else:
                # No-write-allocate: write directly to store, bypass cache
                # Used with write-through + write-around
                self.store.write(key, value)

    def _evict_lru(self):
        k, v = self.cache.popitem(last=False)
        if k in self.dirty:
            self.store.write(k, v)
            self.dirty.remove(k)

    def get(self, key):
        if key in self.cache:
            self.cache.move_to_end(key)
            return self.cache[key]
        val = self.store.read(key)
        if val is not None:
            if len(self.cache) >= self.capacity:
                self._evict_lru()
            self.cache[key] = val
        return val

def benchmark_policies():
    """Compare backing store writes under bursty workload."""
    # Write-through benchmark
    store_wt = SlowBackingStore()
    wt_cache = WriteThroughCache(capacity=3, store=store_wt)
    # Write-back benchmark
    store_wb = SlowBackingStore()
    wb_cache = WriteBackCache(capacity=3, store=store_wb)

    workload = [("A", 1), ("A", 2), ("A", 3), ("B", 10), ("C", 20), ("D", 30), ("A", 99)]

    for key, val in workload:
        wt_cache.put(key, val)
        wb_cache.put(key, val)

    # Write-back still has dirty blocks not yet flushed
    print(f"Write-through store writes: {store_wt.write_count}")  # 7
    print(f"Write-back store writes before flush: {store_wb.write_count}")  # 1 (eviction of B or C)
    wb_cache.flush()
    print(f"Write-back store writes after flush: {store_wb.write_count}")  # 4 (A, B, C, D)

    # Verify final consistency
    assert store_wt.data["A"] == 99
    assert store_wb.data["A"] == 99
    print("Both policies converge after flush.")

# Simulate crash vulnerability
def simulate_crash():
    store = SlowBackingStore()
    cache = WriteBackCache(capacity=2, store=store)
    cache.put("order_123", "PAID")
    cache.put("order_124", "PAID")
    # Crash before flush or eviction - data loss!
    print(f"Store has order_123 before crash? {'order_123' in store.data}")  # False
    print(f"Dirty set size: {len(cache.dirty)}")  # 2 - vulnerable data
    # With write-through, store would already have data

The code highlights three critical implementation details. First, write-through requires no dirty tracking, simplifying eviction to a simple pop. Second, write-back must maintain a dirty set and implement _ensure_capacity that conditionally flushes. Third, the benchmark demonstrates write coalescing: repeated writes to the same key generate only one backing store write under write-back, while write-through generates one per operation.

Step-by-Step Example

Consider a cache with capacity of 3 blocks fronting a database, initially empty. We will execute a sequence of operations and observe how each policy handles state, dirty bits, and backing store synchronization.

Initial state: Cache = {}, Store = {}, Dirty = {}

Step 1: PUT A=10 — Write-through writes A=10 to cache and immediately to store. Store now has A=10. Write-back writes A=10 to cache and marks A as dirty. Store remains empty. Cache for both: {A=10}.

Step 2: PUT B=20 — Similar. Write-through: Cache {A=10, B=20}, Store {A=10, B=20}. Write-back: Cache {A=10, B=20}, Dirty {A, B}, Store {}.

Step 3: PUT A=15 — Update existing key. Write-through overwrites cache and store: Cache {B=20, A=15}, Store {A=15, B=20}. Write-back overwrites cache and keeps dirty flag: Cache {B=20, A=15}, Dirty {A, B}, Store {}. Note write-back coalesced the two writes to A into one pending flush.

Step 4: GET C (miss) — Assume C=30 exists in store from prior population. Both policies miss, fetch C=30 from store, and insert into cache. Cache becomes {B=20, A=15, C=30} at capacity. Write-back marks C as clean because it was fetched from store.

Step 5: PUT D=40 (eviction required) — Capacity is full, so LRU eviction occurs. LRU is B=20. Write-through evicts B silently since store already has B=20. New state: Cache {A=15, C=30, D=40}, Store {A=15, B=20, D=40}. Write-back checks dirty set: B is dirty, so it must flush B=20 to store before eviction. After flush, Store {B=20}, Cache {A=15, C=30, D=40}, Dirty {A, D}. C remains clean, A and D remain dirty.

Step 6: System crash before flush — This is the divergence point. Write-through store contains A=15, B=20, D=40 — all acknowledged writes are durable. Write-back store contains only B=20. Values A=15 and D=40 exist only in volatile cache and are lost. Upon restart, write-back must recover from a write-ahead log or risk silent data loss. This example illustrates why write-back caches in production databases use battery-backed DRAM or persistent dirty logs.

The walkthrough also shows read behavior after eviction. If the application now does GET B, both policies will miss and fetch B=20 from store. In write-through, this is always correct. In write-back, correctness depends on whether the dirty B was flushed before eviction — if flush failed, the store would have stale data.

Complexity Analysis

Both policies provide O(1) average-case operations when implemented with hash maps and doubly linked lists for LRU, but their amortized costs and worst-case behaviors differ significantly due to synchronous versus deferred I/O.

For reads, both policies are identical: O(1) on hit and O(1) plus backing store latency on miss. The cache lookup itself is constant time. The dominant cost is the backing store fetch on miss, which is orders of magnitude slower but occurs with the same frequency in both policies assuming identical hit rates.

For writes, write-through has deterministic O(1) cache update plus O(L) backing store latency where L is the store write latency, incurred on every operation. There is no amortization — each write pays the full cost. Write-back has O(1) cache update for the common case, with occasional O(L) cost when an eviction triggers a dirty flush. This makes the average write latency much lower, but introduces latency spikes on eviction. In the worst case where every eviction is dirty, write-back degenerates to similar I/O volume as write-through, but still benefits from coalescing.

Space complexity is O(N) for cached entries in both cases, where N is capacity. Write-back adds O(D) additional space for dirty tracking, where D is the number of dirty blocks (D <= N). This is typically a bitset or hash set, negligible compared to data size. However, if the system maintains a write-ahead log for durability, that log adds O(W) space where W is the number of unflushed writes, which can grow unbounded if flushes are infrequent.

The table reveals that write-back optimizes for average-case latency at the expense of worst-case predictability. Systems requiring hard real-time guarantees often prefer write-through because its latency is bounded and predictable, even if higher on average. Systems optimizing for throughput and willing to handle flush logic prefer write-back.

Variations and Optimizations

Buffered Write-Through and Write-Behind Batching

Pure write-through can be optimized with a write buffer that sits between cache and backing store. Instead of blocking the client until the store acknowledges, the write is placed in a FIFO buffer and the client is acknowledged early. A background thread drains the buffer to the store. This retains strong durability if the buffer is non-volatile, while reducing client-perceived latency. However, if the buffer is volatile and power is lost, buffered writes are lost — effectively degrading to write-back semantics.

Write-back is often enhanced with batching and coalescing. Rather than flushing each dirty block individually on eviction, the system accumulates dirty blocks and flushes them in sorted order or as a single transaction. This enables sequential I/O, reduces seek time on disks, and allows group commit in databases. Linux's pdflush and modern database checkpointing are examples of batched write-back.

Write-Allocate vs Write-Around

These policies handle write misses — writes to keys not currently cached. Write-allocate, also called fetch-on-write, loads the block into cache on a write miss, then performs the write in cache. This is natural for write-back because the newly allocated block will be marked dirty and flushed later. Write-around, also called no-write-allocate, bypasses the cache and writes directly to the backing store. This avoids polluting the cache with write-only data that may never be read again.

The combination matters: write-through is typically paired with write-around to avoid caching data that is written once and not read, while write-back is paired with write-allocate to maximize coalescing. Choosing incorrectly can cause cache thrashing. For example, a bulk load that writes millions of keys with write-allocate would evict the entire working set, destroying hit rate for subsequent reads.

Hybrid and Adaptive Policies

Modern systems often use adaptive or hybrid approaches. An adaptive cache monitors workload characteristics and switches policies dynamically. If it detects a read-heavy phase, it may favor write-through for simplicity. If it detects bursty writes to the same keys, it switches to write-back to coalesce. Some CPU caches implement a hybrid where clean lines use write-through and dirty lines use write-back, or where the L1 is write-back and the L2 is write-through to main memory.

Another optimization is early flush or idle write-back, where the system opportunistically flushes dirty blocks during idle periods rather than waiting for eviction pressure. This smooths I/O spikes and reduces the amount of dirty data at risk during a crash. Combined with non-volatile write buffers, this provides near write-back performance with near write-through durability.

Real-World Applications

The write-through vs write-back cache decision manifests across the entire computing stack, from silicon to distributed systems. Each layer makes a deliberate trade-off based on its durability and performance requirements.

At the hardware level, CPU caches have historically used both. Early processors used write-through for simplicity, but modern L1 and L2 caches almost universally use write-back because the performance gap between CPU and DRAM is enormous — a write-through L1 would stall the pipeline on every store. The L3 or last-level cache may use write-through to main memory for coherence simplicity in multi-socket systems. Disk controllers and RAID cards use write-back with battery-backed cache to accelerate writes while surviving power loss; enterprise storage arrays advertise write-back cache with supercapacitors as a key performance feature.

In operating systems, the page cache is a classic write-back cache. When an application writes to a file, the data goes into the page cache and is marked dirty. The kernel's flusher threads periodically write dirty pages to disk. The fsync and sync system calls provide explicit flush control for applications needing durability, such as databases. In contrast, direct I/O and write-through file systems like those used for database redo logs bypass the page cache to ensure immediate durability.

In distributed systems and web infrastructure, the choice is equally critical. Redis and Memcached as look-aside caches are often used with write-through at the application layer: the application writes to the database and then invalidates or updates the cache. This ensures cache and database stay consistent but adds latency. Write-back is common in write-heavy services like analytics ingestion, where Kafka or similar logs buffer writes and downstream consumers flush to data warehouses in batches. Content Delivery Networks use write-through for origin fetches to ensure edge caches do not serve stale content after a purge.

Databases deserve special attention because they use write-back internally but achieve durability through write-ahead logging. The buffer pool is a write-back cache for data pages, but every modification is first recorded in a sequential redo log that is written through to disk. On crash, the log replays to restore dirty pages. This hybrid gives the performance of write-back with the durability of write-through, at the cost of double-write overhead for log and page.

Comparison with Alternatives

Write-through and write-back are not the only write policies. Understanding their alternatives helps in selecting the right tool for a given workload. The key dimensions are write latency, read latency after write, durability, complexity, and backing store load.

Write-around bypasses the cache on writes, sending data directly to the backing store. It is useful when writes have poor temporal locality — data written is unlikely to be read soon. It prevents cache pollution but means the next read for that key will be a miss. Write-allocate versus no-write-allocate is orthogonal and determines whether a write miss causes a cache line allocation.

Write-combining is a variant of write-back that merges multiple writes to the same cache line or adjacent lines before flushing, often used in GPU and network buffers. Read-through versus cache-aside affects read path but interacts with write policy: a read-through cache automatically populates on miss, while cache-aside leaves population to the application.

The table makes clear that no single policy dominates. The optimal choice depends on workload write ratio, locality, durability requirements, and acceptable complexity. Many production systems combine policies: for example, using write-back for hot keys and write-through for cold or critical keys, or using write-around for bulk imports while using write-back for interactive traffic.

Common Mistakes and Best Practices

One of the most frequent mistakes is deploying a write-back cache without a durability plan. Developers enable write-back for performance, see latency drop, and ship to production, only to discover data loss after a crash or restart. Every write-back cache must answer: where is the dirty data logged before acknowledgment? Best practice is to pair write-back with a write-ahead log, persistent queue, or battery-backed memory, and to test crash recovery regularly with fault injection.

Another pitfall is ignoring cache coherence in distributed deployments. With write-through, invalidation is simple because the backing store is always current; any node can read from the store after invalidation. With write-back, a node reading from the backing store may see stale data if another node's cache holds a dirty copy. Solutions include using a centralized cache like Redis with proper invalidation, implementing a coherence protocol, or ensuring all reads go through the cache layer rather than bypassing to the store.

Cache stampede and thundering herd effects are exacerbated by write policies. If many clients write the same key simultaneously under write-through, the backing store can be overwhelmed by duplicate writes. Under write-back, concurrent writes can cause lost updates if not properly synchronized. Use atomic operations, compare-and-swap, or per-key locking to serialize writes. For write-back, consider versioning or last-write-wins with vector clocks if eventual consistency is acceptable.

Best practices for operation include monitoring dirty ratio and flush lag. Alert if dirty blocks exceed a threshold or if flush latency grows, as this indicates the backing store cannot keep up. Implement periodic checkpointing and idle flushing to bound recovery time. For write-through, monitor backing store write latency as it directly affects client latency; consider circuit breakers to fail fast if the store becomes slow. Always provide an explicit flush or sync API for callers that need durability on demand, even in a write-back system.

• Always define durability SLAs before choosing a policy — if zero loss is required, default to write-through or write-back with WAL.
• Measure workload locality: high temporal locality favors write-back coalescing; low locality favors write-around.
• Implement per-key TTL and size limits to prevent unbounded dirty growth.
• Use non-volatile buffers or logs for write-back in production; never rely solely on volatile DRAM for acknowledged writes.
• Test failure scenarios: kill cache process mid-write, simulate power loss, and verify recovery correctness.
• Document write miss policy explicitly — write-allocate vs no-allocate has major impact on hit rate.

Interview Questions

1. What is the difference between write-through and write-back, and when would you choose one over the other?

This question tests fundamental understanding. A strong answer defines both: write-through synchronously writes to cache and backing store on every operation, ensuring strong consistency and durability at the cost of higher write latency and store load. Write-back writes only to cache, marks the block dirty, and defers store updates until eviction or flush, providing low latency and coalescing but risking data loss on crash. Choose write-through when durability and simplicity outweigh performance, such as financial systems or session stores. Choose write-back when throughput and write coalescing are critical and you can tolerate or mitigate the durability window with a WAL, such as CPU caches, file system page caches, or analytics pipelines. Mention hybrid approaches and the role of write-allocate vs write-around.

2. How do you prevent data loss in a write-back cache if the system crashes?

The interviewer wants to hear about dirty data protection. Pure write-back loses dirty blocks on crash, so production systems add durability mechanisms. The classic solution is write-ahead logging: before acknowledging the write, append the change to a sequential, durable log that is written through to disk. On recovery, replay the log to reconstruct dirty blocks. Alternatives include battery-backed or non-volatile RAM for the cache itself, replication of dirty blocks to another node before acknowledgment, or periodic checkpointing with bounded staleness. Also discuss flush strategies: synchronous flush on critical writes, asynchronous background flush, and explicit fsync APIs. Emphasize that without such mechanisms, write-back is unsuitable for durable data.

3. Explain dirty bits and their role in cache eviction.

Dirty bits are metadata flags per cache line indicating whether the cached copy is newer than the backing store. On a write, the bit is set to 1. On a flush or clean fetch, it is cleared to 0. During eviction, the cache controller checks the dirty bit: if 0, the line can be dropped silently; if 1, it must be written back to the backing store before eviction to avoid data loss. This check is O(1) but the flush adds I/O latency to the eviction path, causing latency spikes. Follow up by discussing how to track dirty state efficiently using a hash set or bitset, and how batch flushing can amortize the cost. Mention that write-through caches do not need dirty bits because they are always clean.

4. You have a web application with 90% reads and 10% writes. Which cache write policy would you use for the database cache and why?

For a read-heavy workload, both policies can work, but the decision hinges on write durability needs. With only 10% writes, the overhead of write-through is limited, and its simplicity and strong consistency make it attractive, especially if cache and database must stay synchronized for correctness. Write-through also simplifies invalidation because the database is always current. However, if those 10% writes are bursty or update the same hot keys repeatedly, write-back could still reduce database load through coalescing. A nuanced answer proposes write-through with write-around for the database cache, combined with TTL and invalidation on update, and notes that if the database is the system of record and cache is just a performance layer, write-through is safer. If the cache is used as a primary store with asynchronous persistence, write-back with periodic flush may be justified.

5. How does write-allocate vs no-write-allocate interact with write-through and write-back?

This tests deeper cache architecture knowledge. Write-allocate means a write miss allocates a cache line, fetching the block from the backing store or creating it, then performing the write in cache. No-write-allocate, or write-around, writes directly to the backing store without allocating. Write-back is typically paired with write-allocate because the newly allocated line will be marked dirty and benefit from future coalescing; allocating avoids an extra store write. Write-through is typically paired with no-write-allocate to avoid polluting the cache with data that may not be read again, since every write already goes to the store. Choosing the wrong pairing causes performance pathologies: write-allocate with write-through wastes bandwidth by fetching a block only to immediately overwrite it and write it back, while no-write-allocate with write-back misses coalescing opportunities. Discuss how workload locality determines the best pairing.