Caché y escalado de bases de datos

Escalar cómputo agrega capacidad. Este tema hace lo contrario: elimina la necesidad de agregarla. Primero sacando de encima las lecturas que se repiten, y después escalando la capa de datos que tiene que atender lo que queda. Son 3 lecciones que recorren la skill 2.1.2 y la skill 2.1.3 del SOA-C03, del edge a la base relacional y de ahí a DynamoDB.

La primera decide dónde vive una caché para que saque carga real: CloudFront delante del origen, ElastiCache delante de la base, y por qué elegir mal suma un servicio que no alivia nada. La segunda escala Amazon RDS y Aurora, que resuelven el mismo problema con mecanismos opuestos. La tercera cambia de modelo por completo, porque en DynamoDB no eliges el tamaño de una instancia sino unidades de capacidad que se reparten entre particiones que nunca ves.

Qué cubre este tema

• La cache key de CloudFront, las cache policies administradas y las 3 fallas de cache key que hunden el hit ratio
• El recorte de TTL: cómo el Minimum TTL, el Maximum TTL y el Default TTL negocian con Cache-Control del origen
• Invalidación con su cupo gratuito y sus trampas, nombres de archivo versionados, y Origin Shield
• Lazy loading, write-through y TTL en ElastiCache, con la falla que carga cada estrategia
• Los motores de ElastiCache, las métricas que diagnostican y el umbral de CPU de los motores de un solo hilo
• Standby Multi-AZ contra read replica contra Aurora Replica, y qué puede servir lecturas de verdad
• Autoscaling de almacenamiento de RDS y RDS Proxy, con sus condiciones y sus límites exactos
• El volumen de cluster de Aurora, sus endpoints, Aurora Auto Scaling y la capacidad en ACUs de Serverless
• RCUs, WCUs, redondeo y consistencia, on-demand contra provisioned, y auto scaling de tablas
• Burst capacity, capacidad adaptativa, particiones calientes y qué cachea DAX y qué deja pasar de largo

Por qué importa

Las preguntas de este tema casi nunca piden una definición. Te dan un síntoma con números y te piden la causa: un objeto que sigue en la caché aunque el origen dijo no-store, una tabla que se throttlea con capacidad de sobra, una política de Aurora Auto Scaling que no dispara con 2 readers clavados al 90 por ciento. En los 3 casos la respuesta correcta sale de saber dónde se aplica realmente el límite, no de recordar qué hace el servicio.

Ese mismo razonamiento es el que usas en una guardia. Una base de datos saturada tiene varias salidas posibles, y elegir entre cachear, agregar réplicas, cambiar el modo de capacidad o rediseñar la clave depende de saber cuál de esas cosas está apretando.