Tecnología e Infraestructura → Niveles de caché y almacenamiento de datos

Niveles de caché y almacenamiento de datos

1) Por qué se necesita un caché multicapa

El caché es una ruta de respuesta corta sin ir a subsistemas «caros» (DB, APIs externas, redes). La multicapa distribuye la carga: el navegador → CDN/edge → la capa de aplicación → el caché distribuido → la base de datos/almacenamiento. Objetivos: reducir la P95/P99, descargar el origin, soportar los picos más firmemente y abaratar el byte.

2) Mapa de niveles de kash

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh: caché de respuesta rápida para GET seguros.
4. Aplicación (in-process): LRU/LFU, near-cache para llaves «hot», milisegundos.
5. Caché distribuido (Redis/Memcached): capa principal para altavoces.
6. Caché BD: búferes Pg/Innodb, PgBouncer multiplexado, vistas materializadas.
7. Sistemas de disco/objetos: snapshots precomputados, caché de blob (por ejemplo, S3 + CDN).

Principio: "cuanto más cerca del usuario - más corto es el TTL y menos personalización; cuanto más cerca de los datos, más rica es la política de consistencia".

3) Patrones de caché

Cache-Aside (Lazy): leemos → bajo MISS enviamos desde la fuente → ponemos en caché. Simple, da control de TTL.
Read-Through: la aplicación lee a través de un caché que él mismo saca de la fuente. Es conveniente centralizar la política.
Write-Through: la grabación va en caché y a la fuente de inmediato. Es más consistente, pero más caro de grabar.
Write-Back (Write-Behind): escribimos en caché, la fuente se actualiza asincrónicamente (cola). Alta velocidad, se requieren garantías de entrega e idempotencia.
Refresh-Ahead: en claves «top», actualizamos el valor a TTL caducado.

Dónde qué: tarjetas de juegos/catálogos - cache-aside/read-through; contadores/mandos - write-back + CRDT/agregaciones; guías de divisas/límites - leer-a través con TTL controlada.

4) Claves, segmentación y Neuming

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
Incluya en la clave sólo lo que realmente cambia la respuesta (región, moneda, idioma, versión del esquema).
Versificación de esquemas: En caso de cambios incompatibles - aumentar el 'vN' en la clave, evitando la purgación masiva.
Namespacing por producto/tenant: 'tenant: {t}:...' - crítico para multi-tenant.
Un filtro de bloom sobre la «existencia de una clave» puede reducir las subidas a la fuente.

5) TTL, frescura y discapacidad

• estática (archivos hash): 30-365 días + 'immutable';
• catálogos/pancartas: 5-60 minutos + 'stale-while-revalidate';
• mandos/cotizaciones: 2-15 segundos;
• manuales (monedas/límites): 1-10 minutos.
• Discapacidad por eventos: publicamos 'product. updated '→ discapacidad de clave de punto/prefijo.
• Tag-based purge: limpieza de grupo por etiqueta (lanzamiento de promoción/catálogo).
• Soft-Expiry: después de la TTL, damos lo obsoleto como 'stale', en paralelo a la actualización (SWR/SIE).
• Versioned Keys> purge masivo: más barato y más seguro.

6) Stampede, llaves «calientes» y competencia

• Solo vuelo (request coalescing): un líder actualiza la clave, el resto está esperando.
• Jitter TTL: desenfoque las expiraciones, evitando el colapso de un solo momento.
• SWR localmente: el valor caducado se da al usuario, en el fondo actualizamos.

• replicación de la clave «caliente» en varias ranuras 'key # 1.. N' distribuida por lectura;
• near-cache en la memoria del proceso;
• prewarm/refresh-ahead antes de los picos (torneos/partidos).
• Límites en concarrency actualización para llaves pesadas.

7) Consistencia y capas cruzadas

Write-invalidate: al escribir en la fuente, invalide sincrónicamente las claves correspondientes (pub/sub).
Read-repair: si hay discrepancias, actualice el caché con el valor correcto.
Eventual vs Strong: las transacciones monetarias críticas se leen directamente/con TTL corto; UI-vitrinas y estadísticas - eventual.
CRDT/agregadores: para contadores/rankings distribuidos - estructuras «merge-safe» (G-Counter, Top-K en hilos).
Discapacidad en cascada: la actualización de «juego» invalida la tarjeta + lista + caché de recomendaciones personalizado.

8) Serialización, compresión y formato

Formatos: protobuf/MessagePack más rápido que JSON; para CDN/navegador - JSON con Brotli.
Compresión en Redis: beneficiosa para objetos> 1-2 KB, pero cuidado con la CPU.
Respuestas parciales/campos bajo demanda: menos bytes → menos TTFB y RAM.

9) Políticas de desplazamiento y tamaño

LRU (predeterminado): seguro; LFU - mejor para el contenido «popular».
Tamaño de las claves/valores: mantener bajo control (métricas 'avg value size', 'max').
Cuotas de namespace/tenant para que un producto no «coma» todo el caché.

10) Seguridad y PII/PCI

Datos personales/financieros - no caché en CDN/edge y en capas compartidas; utilice tokens/proyecciones.
Encriptación de valores sensibles en Redis a través de crypto de lado cliente (con precaución por pérdidas de control TTL).
ACL estrictas y aislamiento de redes; NAT/IP fijos para egresar a los proveedores.

11) Observabilidad y SLO del kash

• Hit Ratio (por capas y prefijos), Origin Offload.
• TTFB/P95/P99 antes/después del kash, Latency Redis.
• Evictions, OOM, keyspace hits/misses.
• Stampede rate (proporción de actualizaciones paralelas), tiempo de refresco.
• Stale served % и Freshness lag.

• Catálogo de juegos: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (edge).
• Referencias API: Revalidation-hit ≥ 60%, P95 ≤ 200 ms.
• Redis: Operación P99 ≤ 5 ms, evictions no más del 1% por hora.

12) FinOps: costo del kash

$/mes GB RAM vs $/RPS origen: calcular el punto de retorno.
Offload y egress: CDN + Redis reducen el tráfico saliente de origen regional.
Image/WebP/AVIF y las desnormalizaciones producen el mayor ahorro de bytes.
Limite el «MISS caro»: analista de «bytes × MISS × región».

13) Ejemplos (fragmentos)

13. 1 Cache-Aside con un solo vuelo (pseudocódigo)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2 Publicación de la discapacidad por evento

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

El Consumer está suscrito al canal y hace que 'DEL '/' PUBLISH' tenga las claves/etiquetas adecuadas.

13. 3 Clave con la versión del diagrama y local

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) Lista de verificación de implementación

1. Mapa de niveles de caché y matriz TTL (estático/semi-estático/API).
2. Llaves de Neyming: dominio, versión del esquema, local/región/moneda, tenant.
3. Seleccione el patrón per-endpoint (aside/read-through/write-through/back).
4. SWR/SIE, single-flight y TTL-jitter contra stampede.
5. Discapacidad por eventos (pub/sub), tag-purge para grupos.
6. Cerca-cache para las llaves «calientes» y prewarm antes de los picos.
7. Formatos y compresión (protobuf/MsgPack, Brotli), control de tamaño.
8. Políticas de LRU/LFU, cuotas de namespace/tenant.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Seguridad: no-store para personal, tokenización, red/ACL.

15) Anti-patrones

'no-cache' «por si acaso» y los rechazos de TTL son cero offload.
La clave incluye todos los títulos/query → la explosión de cardinalidad.
Purge masivo «todo CDN/Redis» en cada lanzamiento.
Falta de protección contra stampede y caducidad de "top keys' de una sola vez.
Redis común único sin cuotas ni aislamiento; el tenant «caliente» se come todo el caché.
Caché de respuestas personales a edge/CDN.
No hay telemetría freshness/evictions → control ciego.

16) Contexto iGaming/Fintech: notas prácticas

Leadboards/ratings: TTL 2-10 s, aggregate-streams + CRDT, SWR en caso de fallas.
Catálogo de juegos/banners: CDN + Redis; clave: región/moneda/idioma; discapacidad por etiquetas «promo: update».
Estados de pago: sin caché en la ruta de escritura; lectura - TTL corta (≤3 -5 s) o consulta directa.
KYC/AML respuestas: caché no PII derivados (estados), no almacenar imágenes/documentos en Redis.
Ruta VIP: namespace/pool Redis independiente, servicio prioritario.

Resultado

Una estrategia de caché fuerte es la arquitectura de niveles, patrones de actualización correctos, TTL/discapacidad pensada, resistencia a stampede, claves y versiones ordenadas, y observabilidad y FinOps. Siguiendo estos principios, estabilizará las colas de los P95/P99, reducirá la carga de las fuentes y obtendrá un costo predecible de milisegundos, exactamente donde es más importante para el producto y el negocio.