¿Qué es el patrón de caché write-around, y cuándo supera al write-through?

#Tres formas de ubicar una escritura respecto al caché

Toda estrategia de escritura en caché responde a la misma pregunta: cuando un dato cambia, ¿qué pasa con el caché en el momento mismo de la escritura? Hay tres respuestas habituales:

• Write-through — la escritura va al caché y a la base de datos juntas (o el caché está delante y escribe a través hacia la base de datos), de modo que el caché queda actualizado inmediatamente después de una escritura exitosa.
• Write-back (write-behind) — la escritura llega primero al caché y se vuelca a la base de datos de forma asíncrona, más tarde.
• Write-around — la escritura va directamente solo a la base de datos. El caché no se toca en absoluto (o se invalida explícitamente, no se actualiza), y la única forma en que una entrada termina en el caché es a través del camino normal de lectura (cache-aside: leer, fallar, cargar de la base de datos, poblar el caché).

Write-around suele ser el patrón que la gente olvida que existe, porque parece "no hacer nada especial" —pero precisamente ahí está su valor.

#Cómo se ve write-around en la práctica

import json
from typing import Optional
import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)
CACHE_TTL_SECONDS = 300


def write_around_update(product_id: str, fields: dict) -> None:
    """Write-around: la escritura va directamente a la base de datos.
    No fijamos el caché aquí -- ese es justamente el punto del patrón.
    Sí invalidamos cualquier copia obsoleta para que una lectura
    inmediatamente posterior no la devuelva."""
    db.update_product(product_id, fields)
    r.delete(f"product:{product_id}")


def read_with_cache_aside(product_id: str) -> Optional[dict]:
    """El caché solo se puebla de forma perezosa, ante un miss de lectura."""
    key = f"product:{product_id}"
    cached = r.get(key)
    if cached is not None:
        return json.loads(cached)

    product = db.get_product(product_id)
    if product is None:
        return None

    r.setex(key, CACHE_TTL_SECONDS, json.dumps(product))
    return product

Nota lo que falta comparado con write-through: no hay ningún r.set(key, nuevo_valor) en el camino de escritura. El único trabajo relacionado con el caché que tiene la función de escritura es asegurarse de que no quede rondando una copia obsoleta — elimina, nunca fija.

#Cuándo gana write-around

Write-around es la opción correcta por defecto siempre que un dato se escribe muchísimo más de lo que se lee, o cuando el registro concreto que acabas de escribir es poco probable que sea lo próximo que se lea. Ejemplos clásicos: importaciones masivas de datos, logs de auditoría/eventos, ingestión de analítica, un script de backfill actualizando millones de filas de madrugada, o cualquier tabla intensiva en escritura que se consulta sobre todo de forma agregada y no por la fila exacta que acabas de tocar. En todos estos casos, write-through significaría pagar el costo de una escritura en caché (un round-trip de red extra, un posible costo de serialización, presión sobre la memoria del caché) para datos que, estadísticamente, es poco probable que se lean del caché antes de que expire su TTL de todas formas. Write-around evita contaminar el caché con datos fríos y mantiene el camino de escritura rápido y simple —es un salto de red menos por escritura, y no añade un nuevo modo de fallo (¿qué pasa si la escritura al caché falla pero la de la base de datos tuvo éxito?) al camino de escritura.

#Dónde te cuesta

El costo es la imagen especular de su beneficio: la primera lectura después de una escritura siempre es un miss garantizado. Si tu aplicación (o la misma request) vuelve a leer el valor que acaba de escribir —un patrón clásico de "leer tu propia escritura", como mostrar una página de confirmación justo después de un envío de formulario— write-around obliga a que esa primera lectura vaya a la base de datos, añadiendo latencia justo cuando un usuario está mirando. Write-through no tiene este problema, porque el caché ya contiene el valor fresco en el instante en que la escritura se completa.

#Comparación directa