Una base de datos es el componente de una aplicación que almacena información, garantizando su persistencia tras un reinicio de la aplicación, un fallo del servidor o un corte de energía. Posteriormente, la aplicación puede recuperar dichos datos con formatos específicos, como un registro concreto mediante su identificador o una lista filtrada por usuario.
Para ilustrar el concepto de “datos” de forma práctica, consideremos una aplicación sencilla de gestión de tareas. Cada tarea constituye un registro con campos como task_id, user_id, title, completed y created_at; la aplicación requiere dos funciones básicas: una para crear una tarea y otra para listar las tareas de un usuario.
En una configuración básica de un solo servidor, el cliente envía peticiones HTTP a un servidor de aplicaciones, el cual lee y escribe registros en una única base de datos. La base de datos garantiza la integridad aplicando reglas —como “un registro de tarea se escribe una sola vez por petición”—, aunque también introduce latencia, dado que las operaciones de lectura y escritura requieren tiempo de procesamiento en disco y memoria. Analicemos las rutas de ambas peticiones mediante un diagrama de bloques.
En una solicitud para crear una tarea, el servidor de aplicaciones valida los datos de entrada, solicita a la base de datos que inserte una nueva fila de tarea y, posteriormente, devuelve el nuevo task_id al cliente. El cliente percibe la escritura como permanente solo después de que la base de datos la confirma; por ello, la base de datos constituye un elemento crítico para garantizar la integridad de los datos.
En una solicitud para listar tareas, el servidor de aplicaciones pide a la base de datos todas las tareas cuyo user_id coincida (a menudo ordenadas por created_at) y luego formatea la respuesta. Cuando dicha consulta escanea más filas de las necesarias, la base de datos realiza un mayor esfuerzo y el tiempo de espera del cliente aumenta; por tanto, el rendimiento pasa a depender de la eficiencia con la que la base de datos localiza las filas coincidentes.
A medida que más usuarios añaden tareas, el primer fallo visible suele ser la ralentización de la función de listado de tareas, ya que la base de datos debe leer un volumen excesivo de datos para responder a una sola consulta. A continuación, un usuario con mucha actividad o una lista compartida pueden provocar esperas por bloqueo cuando múltiples operaciones de escritura intentan actualizar la misma fila o conjunto de filas; esto hace que las solicitudes se encolen en lugar de completarse en paralelo. Por último, si el proceso o la máquina de la base de datos (al tratarse de una instancia única) deja de funcionar, toda la aplicación interrumpe su servicio, dado que cada solicitud depende de ella. El siguiente diagrama señala estos tres puntos críticos sobre una misma línea base.