Introducción: Caché auto-cargada
En Read-Through, la caché actúa como fachada: cuando hay un miss, ella misma consulta la base y guarda el resultado.
La aplicación simplifica su lógica de lectura, delegando la carga en el proveedor de caché.
Es ideal cuando quieres centralizar el comportamiento de caché en un solo punto.
Prompt: Read-through cache auto-load, clean minimal style.
1. Naturaleza: Biblioteca con bibliotecario
El lector pide un libro. Si no está en estantería, el bibliotecario lo trae del depósito.
El lector no necesita conocer la ubicación: todo pasa por la misma interfaz.
Prompt: Librarian fetching book, soft illustration.
2. Mundo Real: Perfil de usuario
Una API consulta caché; si no existe el perfil, la caché lo trae del repositorio y lo deja listo.
Esto evita duplicar lógica de caché en múltiples servicios.
Prompt: User profile read-through flow, clean flat style.
3. Implementación en C#: Código Paso a Paso
// Pseudocódigo: proveedor de caché con loader
var profile = await cache.GetOrLoadAsync(
key, () => repo.GetByIdAsync(key));Requiere soporte del proveedor (Redis, Memcached, etc.) o un wrapper propio.
Define TTL y políticas de invalidación para evitar datos obsoletos.
4. Read-Through vs Cache-Aside
Read-Through centraliza la carga en la caché; Cache-Aside lo controla la aplicación.
Read-Through reduce código duplicado, pero exige una caché más inteligente.
5. Diagrama UML
Prompt: UML diagram of read-through cache, clean vector layout.
Prompt: Read-through flow diagram, minimal infographic style.
⚠️ Cuándo NO Usar Read-Through
- Si necesitas lógica de carga específica por caso.
- Si tu caché no soporta loaders confiables.
- Si el costo de fallos de carga es alto.
💪 Ejercicio
Implementa un wrapper de caché con GetOrLoadAsync y TTL configurables.
Conclusión
Read-Through simplifica lecturas y centraliza el comportamiento de caché.
Es una buena opción cuando quieres consistencia de acceso y menos código duplicado.