Arquitectura de referencia: gran escala / alto tráfico
A medida que crece el tráfico, hay un orden correcto para proteger la base de datos: primero las palancas sencillas y baratas, luego las complejas. Este árbol recorre paso a paso el orden escalado vertical → réplica de lectura → sharding, los patrones de caché (cache-aside, write-back), el buffering con una cola + backpressure, el rate limiting, el aislamiento de la base de datos con bulkheads/circuit breakers y la prevención de puntos calientes. Principio básico: deje para el final las decisiones difíciles de revertir, como el sharding, y agote primero las mejoras baratas.
¿Dónde está el cuello de botella: una sola instancia saturada, lecturas o escrituras intensas, o tráfico a ráfagas?
Para resolver un problema de escalado en el lugar adecuado, identifique primero el cuello de botella. ¿Una sola instancia está saturada de CPU/memoria, predominan las lecturas, las escrituras llegan al límite, o picos repentinos de tráfico aplastan la base de datos? Cada caso apunta a un componente distinto.
- Una sola instancia está saturada; aún no he probado las palancas sencillas
- Las lecturas son muy intensas y van en aumento
- Picos repentinos de tráfico / carga a ráfagas aplastan la BD
¿En qué paso de escalado está: vertical, réplicas de lectura o sharding?
El escalado tiene un orden correcto. El escalado vertical (hardware más potente) es el primer paso más sencillo; luego reparte las lecturas entre réplicas; solo cuando un único primario ya no puede con las escrituras pasa al particionamiento horizontal (sharding). ¿Dónde está usted?
- Aún no he ampliado el hardware / agotado el ajuste básico
- Las escrituras caben en una instancia, pero necesito repartir la carga de lectura
- Un único primario ya no puede con la carga de escritura
¿Cómo protegerá la base de datos de la carga: buffering, limitación o aislamiento?
Escalar no siempre consiste en hacer más grande la BD; a menudo consiste en protegerla de la sobrecarga. ¿Suavizará los picos repentinos de escritura con una cola, limitará la tasa de solicitudes entrantes (rate limiting), o impedirá que una sola dependencia haga caer todo el sistema (bulkhead/circuit breaker)?
- Quiero suavizar los picos repentinos de escritura
- Quiero limitar/repartir de forma equitativa la tasa de solicitudes entrantes
- No quiero que una dependencia que falla haga caer todo el sistema
Recomendación: primero escalado vertical y ajuste básico
El paso más barato y menos arriesgado es el escalado vertical: añadir más CPU/RAM/discos más rápidos y corregir lo básico (índices, connection pooling, parámetros de memoria). Agote estas mejoras antes de decisiones complejas como el sharding.
Recomendación: reparta las lecturas con réplicas de lectura
Las escrituras permanecen en un único primario mientras el tráfico de solo lectura se reparte entre una o más réplicas. Es mucho más sencillo que el sharding y resuelve la mayoría de las cargas con lectura intensiva; el primario queda solo para las escrituras y las lecturas críticas para la consistencia.
Recomendación: sharding (particionamiento horizontal) como último recurso
Cuando un único primario no puede con la carga de escritura, se dividen los datos por una clave en varias piezas independientes (shards); cada shard asume parte de las escrituras. Es potente pero difícil de revertir; complica las consultas y transacciones entre shards, por lo que se deja para el final.
Recomendación: patrones de caché (cache-aside + write-back)
Con alto tráfico y lectura intensiva, se coloca una caché en memoria (Redis) delante de la BD y se sirven la mayoría de las lecturas sin que lleguen nunca a la BD. Para escrituras de gran volumen, write-back acumula las escrituras y las vuelca a la BD por lotes, aliviando el primario.
Recomendación: buffering con una cola (backpressure)
Para evitar que los picos repentinos de escritura lleguen directamente a la BD, se interpone una cola duradera (p. ej. Kafka/una cola de mensajes) y se consumen las escrituras al ritmo que la BD puede sostener. La cola absorbe el pico; en lugar de fallar de forma síncrona, el sistema funciona con una latencia controlada (backpressure).
Recomendación: rate limiting (limitar la tasa de solicitudes)
Limitando las solicitudes entrantes por origen (rate limiting), evita tanto el abuso como que un solo cliente consuma todos los recursos. Acotar la carga que llega a la BD mantiene el sistema predecible y equitativo.
Recomendación: bulkhead + circuit breaker (aislamiento)
Para evitar que una dependencia (p. ej. una BD que se ralentiza o un servicio externo) haga caer todo el sistema, se dividen los recursos en compartimentos (bulkheads) y se cortan temporalmente las llamadas a una dependencia que falla continuamente (circuit breaker). Así, un fallo parcial no se propaga a todo el sistema.