El computed pattern en MongoDB te permite precalcular valores como totales o promedios al momento de escribir, en lugar de calcularlos cada vez que lees el documento. Es ideal para desarrolladores que diseñan bases de datos con operaciones frecuentes de lectura, como ecommerce, sistemas de calificaciones o métricas de negocio.

Cuándo aplicar el computed pattern en tu modelado

Dentro de la metodología de modelado en MongoDB, los patrones aparecen en el último paso. Antes ya analizaste el caso de negocio, identificaste entidades, definiste qué queries se ejecutan más y mapeaste relaciones decidiendo si embeber o referenciar. Ahora toca optimizar.

El caso más natural para aplicar este patrón son las órdenes de compra de un ecommerce [04:30]. Imagina un carrito al que el usuario va agregando productos uno a uno. Cada producto tiene precio y cantidad, y tú necesitas mostrar el total de la orden.

Si cada vez que renderizas la factura recorres todos los ítems y multiplicas precio por cantidad, estás gastando CPU innecesariamente. Aquí entra el patrón: calculas el total al escribir, no al leer.

¿Qué es el computed pattern en MongoDB? Es un patrón de diseño que precalcula valores derivados (totales, promedios, sumas) en el momento de la escritura y los almacena en el documento, evitando recalcularlos en cada lectura.

Cómo implementar el computed pattern paso a paso

El ejercicio parte de una estructura de orden de compra con cuatro campos: el usuario que origina la compra, la fecha, un array vacío de ítems y un campo total inicializado en cero [03:20].

En lugar de insertar todos los productos de golpe, simulas el comportamiento real de un carrito: el usuario va agregando productos dinámicamente. Cada vez que agrega uno, ejecutas un updateOne con dos operadores en paralelo.

Qué operadores de MongoDB necesitas

Para que el patrón funcione necesitas combinar dos operadores en la misma operación de actualización:

• $push: agrega el nuevo producto al array de ítems con su precio, cantidad y referencia.
• $inc: incrementa el campo total con el resultado de precio multiplicado por cantidad.
• objid: referencia el ID específico de la orden que estás actualizando.

La lógica es directa. Si el primer producto vale 12 dólares y el usuario pide una unidad, el $inc suma 12 al total [06:40]. Si después agrega otro producto de 45 dólares con cantidad de tres, el $inc suma 135. El total queda en 147 sin que tengas que recorrer el array.

Por qué precalcular ahorra recursos

Cuando consultas la orden con un findOne, el total ya está listo. No hay multiplicaciones en tiempo de lectura, no hay agregaciones costosas, no hay latencia adicional al renderizar la factura.

Esto importa porque la base de datos hace menos trabajo en cada query, y el frontend recibe la respuesta casi inmediata. La regla de fondo: mueves el costo computacional desde la lectura hacia la escritura, que suele ser menos frecuente.

Por qué el computed pattern optimiza CPU y rendimiento

Un caso real ilustra el impacto. En un sistema de evaluaciones tipo ICFES en Colombia [09:10], cada estudiante presentaba un examen con un score final. Originalmente, cada vez que un profesor consultaba la lista de un salón, la base de datos recalculaba el score de cada estudiante: revisaba pregunta por pregunta, validaba respuestas correctas y sumaba puntos.

El resultado era una interfaz lentísima. La solución fue aplicar computed pattern: a medida que el estudiante respondía, el sistema iba actualizando el score en el documento. Cuando terminaba el examen, el valor quedaba congelado y la consulta se volvía instantánea.

Otro ejemplo es el revenue de una película proyectada en varias salas. Sumar todos los documentos de cada sala en cada consulta sería costoso. Si precalculas el ingreso acumulado cada vez que cierra una función, la lectura es ligera.

¿Cuándo conviene usar computed pattern? Cuando lees datos con mucha más frecuencia que los escribes, y cuando necesitas valores agregados como totales, promedios o sumas que no cambian todo el tiempo.

Qué criterios usar para decidir

Antes de aplicar el patrón, valida tres condiciones:

1. La operación de lectura es más frecuente que la de escritura.
2. El valor a calcular es derivable de otros campos del documento.
3. Es más eficiente actualizar dinámicamente que computar en cada query.

También recuerda que la lógica de actualización puedes manejarla desde tu backend en Python, JavaScript, .NET o Java. La regla de negocio se ejecuta cada vez que insertas o modificas un producto, manteniendo el documento siempre con el total actualizado.

¿Te gustaría que profundicemos en más patrones de diseño con MongoDB? Déjalo en los comentarios.