Arquitectura de referencia: aplicación OLTP de 3 capas
Las aplicaciones de negocio clásicas (pedidos, pagos, inventario) ejecutan un gran número de transacciones cortas, de una sola fila y críticas para la consistencia (OLTP). Este árbol muestra paso a paso, empezando por identificar el perfil de carga, cuándo introducir la base de datos relacional primaria, un pooler de conexiones, réplicas de lectura, una capa de caché, backup + PITR y monitoreo. El objetivo no es «añadirlo todo desde el principio», sino añadir el componente adecuado a medida que se demuestra cada cuello de botella.
¿Cuál es su perfil de carga: mezcla de transacciones y requisitos de consistencia?
La primera decisión en una arquitectura OLTP es si la carga es realmente transaccional (una mezcla corta de escrituras y lecturas que requiere ACID). ¿Los datos son relacionales por naturaleza y la consistencia es crítica (dinero, stock, pedidos), la carga es mayoritariamente de lectura, o la carga todavía es muy baja?
- Transacciones cortas, consistencia fuerte (dinero/stock/pedidos)
- Predominan claramente las lecturas, pocas escrituras, y el tráfico crece
- La carga es muy baja; ¿basta con la configuración más sencilla?
¿Ha elegido el motor de base de datos primario, y le preocupa la escala?
Un motor relacional es la base adecuada para el núcleo transaccional (PostgreSQL, MySQL/InnoDB, Oracle, SQL Server). Una vez clara la elección del motor, la siguiente pregunta es el escalado: ¿basta por ahora con una sola instancia, o están aumentando el número de conexiones y la carga de lectura?
- El motor está claro; por ahora basta con una sola instancia
- El número de conexiones se ha disparado, los recursos se agotan
- La carga de lectura crece y sobrecarga la instancia primaria de escritura
¿Cómo escalará las lecturas: réplica o caché?
Si la carga de lectura sobrecarga la instancia primaria, hay dos opciones complementarias. Las lecturas que toleran datos ligeramente retrasados, como informes/listados, pueden dirigirse a una réplica de lectura; si se solicitan una y otra vez los mismos datos «calientes», una caché con latencia de microsegundos (Redis) alivia la BD.
- Muchas lecturas de informes/listados; es aceptable un ligero retraso
- Los mismos datos populares se leen una y otra vez
Recomendación: empiece con un único primario + pool + backup
Mantenga la arquitectura sencilla al principio: basta con una única instancia relacional primaria, un pool de conexiones delante y backups periódicos. Añada complejidad solo cuando un cuello de botella medido lo exija.
Recomendación: añada un pooler de conexiones
En OLTP, cuando cada instancia de aplicación abre sus propias conexiones, la BD primaria se ahoga por la sobrecarga de memoria y del planificador con miles de conexiones. Interponer un pooler permite compartir un pequeño número de conexiones reales a la BD entre muchas solicitudes de la aplicación.
Recomendación: añada una réplica de lectura
Las escrituras permanecen en el primario mientras el tráfico de solo lectura (informes, listados, búsquedas) se dirige a una o más réplicas asíncronas alimentadas desde el primario. Esto libera al primario para las escrituras y las lecturas críticas para la consistencia.
Recomendación: añada una capa de caché (Redis)
Si los mismos datos populares (sesiones, catálogo, perfiles, fragmentos de página) se leen repetidamente, coloque una caché en memoria delante de la BD y sirva la mayoría de las lecturas sin llegar nunca a la BD. La latencia baja y la BD primaria se alivia.