Bases de datos

Un servidor backend es solo un proceso en ejecución bajo el control del sistema operativo. Sus variables en memoria desaparecen cuando el proceso se reinicia, falla o se vuelve a desplegar. Eso hace que la memoria sea ideal para el cálculo, pero completamente poco fiable para el almacenamiento a largo plazo.

Los sistemas de producción requieren durabilidad de los datos. Las cuentas de usuario deben seguir existiendo después de un reinicio. Los pedidos deben permanecer registrados después de un despliegue. Los registros deben seguir siendo accesibles para depuración y auditoría.

Una base de datos resuelve esto escribiendo datos estructurados en almacenamiento persistente (normalmente SSD o disco). Mientras que la memoria está optimizada para la velocidad, el almacenamiento está optimizado para la durabilidad. El motor de la base de datos gestiona cómo se escriben, indexan y recuperan los datos de forma segura.

Sin una base de datos, tu sistema no tiene memoria a largo plazo. Se vuelve sin estado de la peor manera posible: incapaz de sobrevivir a un fallo.

Una base de datos no es solo almacenamiento; es un motor de ejecución controlado para los datos.

En el modelo relacional, los datos se almacenan en tablas compuestas por filas y columnas. Cada fila representa un registro, y cada columna representa un atributo. Un esquema define la estructura, los tipos de datos y las restricciones, evitando que se inserten datos inválidos o inconsistentes.

La base de datos también proporciona un motor de consultas. En lugar de leer archivos sin procesar, las aplicaciones envían consultas estructuradas para recuperar o modificar subconjuntos específicos de datos de forma eficiente.

A nivel de sistema, la base de datos es la fuente autorizada de verdad. Garantiza la durabilidad, mantiene la integridad estructural y permite una gestión predecible del estado.

Las bases de datos SQL (sistemas relacionales) organizan los datos en tablas predefinidas con esquemas estrictos. Las relaciones entre tablas se modelan explícitamente, y las fuertes garantías transaccionales son estándar. Esto las hace muy adecuadas para sistemas que requieren integridad y consultas complejas.

Las bases de datos NoSQL relajan los esquemas rígidos. Muchas usan estructuras basadas en documentos o pares clave-valor, lo que permite que los campos varíen entre registros. Esta flexibilidad puede simplificar el desarrollo para modelos de datos que evolucionan rápidamente y puede admitir el escalado horizontal en clústeres distribuidos de forma más natural.

La verdadera diferencia está en el enfoque arquitectónico. SQL prioriza la estructura y la fuerte consistencia. NoSQL prioriza la flexibilidad y la escalabilidad distribuida. Los sistemas de producción a menudo combinan ambos según la carga de trabajo.

Cuando un cliente envía una solicitud HTTP, esta finalmente llega al proceso de tu servidor. Tu handler ejecuta la lógica de la aplicación, pero la mayoría de las operaciones importantes requieren leer o escribir datos persistentes.

El servidor envía una consulta al motor de la base de datos. Esa consulta puede implicar analizar SQL, comprobar permisos, localizar páginas de datos relevantes, usar índices, leer desde disco y ensamblar un conjunto de resultados.

Durante este tiempo, el hilo del servidor normalmente está esperando. En modelos síncronos, se bloquea. En modelos asíncronos, el event loop espera el resultado. En cualquier caso, el progreso depende de que la base de datos termine su trabajo.

Esto es crítico: la interacción con la base de datos suele ser el mayor contribuyente a la latencia en sistemas backend. Consultas deficientes, índices faltantes, viajes de ida y vuelta por la red o retrasos de E/S de disco pueden superar fácilmente el tiempo de cómputo de la aplicación.

Si tu sistema se siente lento, la capa de base de datos suele ser el primer lugar que debes investigar.

Supón que tienes una tabla con un millón de usuarios y buscas una dirección de correo electrónico específica.

Sin un índice, la base de datos puede necesitar revisar cada fila hasta encontrar una coincidencia. Eso es lento, especialmente a medida que la tabla crece.

Con un índice en la columna de correo electrónico, la base de datos mantiene una estructura separada y organizada (similar al índice de un libro). En lugar de recorrer todo, usa esa estructura para localizar rápidamente la fila correcta.

Los índices hacen que las lecturas sean mucho más rápidas, pero no son gratis. Cada vez que insertas, actualizas o eliminas datos, el índice también debe actualizarse.

Si una consulta es inesperadamente lenta, una de las primeras preguntas que debes hacer es: “¿Hay un índice en la columna que se está buscando?”

Considera transferir dinero de la Cuenta A a la Cuenta B.

Paso 1: Restar $100 de la Cuenta A.
Paso 2: Sumar $100 a la Cuenta B.

Si el sistema falla después del Paso 1 pero antes del Paso 2, el dinero desaparece. Eso es corrupción de datos.

Una transacción evita esto. Ambas operaciones se encapsulan dentro de un límite transaccional. La base de datos garantiza que:

• Ambos pasos se completen correctamente, o
• Ningún paso se aplique de forma permanente.

Este comportamiento de “todo o nada” se llama atomicidad. Garantiza que el sistema se mantenga lógicamente consistente incluso durante fallos.

Las transacciones son esenciales en cualquier lugar donde la corrección de los datos importe: finanzas, inventario, autenticación y más.

ACID es un contrato práctico de fiabilidad, no teoría.

Atomicidad evita actualizaciones parciales. Si un paso falla, todo se revierte.

Consistencia garantiza que las restricciones, relaciones y reglas se mantengan después de que una transacción se complete.

Aislamiento protege las transacciones para que no se corrompan entre sí cuando varios usuarios operan simultáneamente.

Durabilidad garantiza que, una vez que la base de datos confirma el éxito, los datos se escriben en almacenamiento persistente y sobrevivirán a un fallo del sistema.

Juntas, estas propiedades hacen que las bases de datos sean fundamentos fiables para sistemas del mundo real.

A medida que aumenta el uso, crece el volumen de consultas. Con el tiempo, un solo servidor de base de datos no puede seguir el ritmo de las solicitudes entrantes.

Una opción es el escalado vertical: actualizar la máquina existente con más CPU, memoria o almacenamiento más rápido. Esta es la solución más sencilla porque la arquitectura sigue siendo la misma. Sin embargo, las mejoras de hardware tienen límites y los costos aumentan rápidamente.

Otra estrategia es añadir réplicas de lectura. En este modelo, una base de datos primaria maneja las escrituras mientras que las copias replicadas atienden las consultas de solo lectura. Esto reduce la presión sobre el servidor primario, aunque puede introducir pequeños retrasos mientras los datos se propagan entre nodos.

Para un crecimiento aún mayor, los sistemas pueden usar sharding. En lugar de almacenar todos los datos en una sola máquina, el conjunto de datos se divide entre varias instancias de base de datos. Por ejemplo, un shard podría almacenar usuarios de A–M y otro de N–Z. Esto aumenta la capacidad total, pero requiere una lógica de enrutamiento cuidadosa y gestión operativa.

Cada uno de estos enfoques mejora la escalabilidad, pero también introduce compromisos en costo, complejidad y consistencia.

La base de datos suele ser la dependencia más crítica en un sistema backend. Cuando se ralentiza o falla, la aplicación refleja el impacto de inmediato.

Si la base de datos deja de ser accesible, los manejadores de solicitudes no pueden completar sus consultas y la aplicación comienza a devolver errores de nivel 500.

Incluso cuando la base de datos está en funcionamiento, las consultas lentas, la falta de índices o la contención por bloqueos pueden aumentar la latencia. Desde fuera, el servidor parece lento, pero en realidad está esperando a la base de datos.

Bajo carga intensa, límites de recursos como el agotamiento de conexiones, el retraso de replicación o la saturación del disco pueden introducir inestabilidad y comportamiento inconsistente.

Muchos “problemas de la aplicación” se originan en la capa de persistencia. Entender esta cadena de dependencias es esencial para diagnosticar problemas en producción.