Recursos de ejecución: memoria volátil, almacenamiento y cómputo

¿Por qué un sistema de reservas que parece guardar perfectamente las plazas durante una demostración de cinco minutos puede perder todas las reservas al día siguiente o cuando tiene éxito y recibe más visitas? La causa más común es confundir la memoria de trabajo (volátil) de un proceso en ejecución con el almacenamiento persistente compartido.

Objetivos y conocimientos previos

Partiendo de Capas de abstracción, aprenderás la diferencia operativa entre memoria volátil (RAM) y almacenamiento no volátil, qué significa que un proceso tenga o no estado propio en memoria (stateful vs. stateless), y cómo evaluar el coste de tiempo y memoria de un procedimiento.

Memoria de trabajo (RAM) frente a Almacenamiento Persistente

Para que el procesador (CPU) evalúe una condición o sume dos importes, los datos deben estar cargados en la memoria de trabajo (RAM) del proceso. Sin embargo, la memoria de trabajo y el almacenamiento persistente tienen propiedades opuestas:

La trampa del estado guardado en variables del proceso

Cuando pides a un agente de IA un prototipo rápido sin especificar los requisitos de persistencia, es muy frecuente que el agente guarde la lista de reservas o los intentos de acceso en una variable o lista en la memoria del propio programa.

En una prueba local de dos minutos, esa lista en memoria parece funcionar: creas una reserva, consultas la lista un segundo después y ahí está. Pero en un entorno real provoca dos fallos graves:

1. Pérdida total ante reinicio o actualización: En cuanto corriges un texto de la aplicación y el servidor reinicia el proceso para aplicar la nueva versión, la lista en memoria vuelve a estar vacía. Todas las reservas desaparecen.
2. Inconsistencia al escalar a más de un proceso:

Por eso, en los sistemas modernos se prefiere que los procesos de aplicación sean sin estado propio retenido (stateless): cada proceso recibe la solicitud, consulta o actualiza el estado en la base de datos persistente compartida y devuelve la respuesta. Así, cualquier proceso puede atender cualquier solicitud y reiniciar un proceso no destruye información.

Y qué es entonces una Caché

Si la memoria RAM es mucho más rápida que ir a la base de datos, ¿no podemos usarla para acelerar lecturas frecuentes (por ejemplo, el título y la descripción de una actividad que leen mil personas por minuto)?

Sí: eso se llama caché. Guardar un dato en caché significa mantener en memoria rápida una copia temporal de un dato cuya fuente de verdad sigue estando en el almacenamiento persistente.

Para usar una caché sin romper la lógica del sistema debes recordar dos reglas:

• La caché es descartable: si se borra, el sistema debe poder reconstruirla leyendo la base de datos. Nunca guardes únicamente en caché un dato que no puedas permitirte perder.
• Toda copia en caché puede quedar desactualizada: si muestras las «plazas disponibles» desde una caché de hace cinco minutos, sirve como orientación visual, pero en el momento de aceptar una nueva reserva debes comprobar y actualizar la fuente de verdad transaccional.

Coste de cómputo y memoria: crecer con el volumen de datos

Además de no perder datos, tus procesos deben caber en la memoria y responder en un tiempo razonable cuando el sistema pasa de tener 10 registros a tener 1.000.000:

• Si para saber cuántas facturas pendientes tiene la clienta C-101 el programa carga en la memoria RAM el millón de facturas de todos los clientes de los últimos diez años y las recorre una por una, agotará la memoria del proceso y bloqueará a los demás usuarios.
• En cambio, si delega el filtrado y el conteo al motor de datos sobre el identificador indexado id_cliente = C-101, solo trae a memoria los pocos registros necesarios.

No necesitas optimizar prematuramente cada línea, pero sí hacer siempre esta pregunta lógica: «¿Qué ocurrirá con el tiempo y la memoria de este paso cuando en lugar de diez registros haya cien mil?».

Practica

Pides al agente que implemente una regla de seguridad: «Si alguien falla su contraseña 5 veces seguidas en menos de 15 minutos, bloquea temporalmente nuevos intentos para esa cuenta». El agente lo implementa guardando un diccionario intentos_fallidos en una variable en la memoria RAM del proceso servidor.

1. Explica cómo podría un atacante saltarse ese límite de 5 intentos si el servicio web tiene 3 procesos servidores funcionando en paralelo repartiendo las peticiones.
2. ¿Qué ocurre con las cuentas que estaban bloqueadas si el servidor se reinicia automáticamente por mantenimiento?
3. Si además el agente decidiera calcular el total facturado del año trayendo a una lista en memoria RAM todos los recibos emitidos desde la creación de la empresa y sumándolos allí cada vez que alguien abre el panel principal, ¿qué recurso físico se agotará a medida que crezca la empresa y qué alternativa conceptual propondrías?

Criterio de comprensión: debes explicar que la memoria RAM es local a cada proceso (permitiendo hasta 15 intentos repartidos en 3 procesos) y volátil al reiniciar, por lo que el estado de intentos debe registrarse en un almacén compartido, y que las agregaciones sobre grandes volúmenes deben resolverse mediante consultas acotadas o totales mantenidos en el almacén de datos en lugar de cargar toda la colección en la RAM del proceso.

Profundiza con IA

Aquí tienes mi análisis sobre los problemas de usar memoria RAM del proceso para el bloqueo de contraseñas y para sumar todas las facturas históricas: [tu respuesta]. Revisa mis argumentos. Después, pregúntame en qué caso sí tendría sentido usar una caché en memoria dentro de este sistema, y qué condición tendría que cumplirse para que esa caché no provoque cobros ni reservas inválidas.

Siguiente lectura

Ya sabemos qué capas y qué recursos físicos sostienen la ejecución. ¿Cómo se escriben las reglas y modelos para que esas capas los ejecuten sin ambigüedad? Continúa con Lenguajes formales: cómo se expresa la lógica sin ambigüedad.