Introducción

Un sistema de inventario puede tener una interfaz moderna, pero si sus datos se pierden durante una falla o una operación equivocada, el negocio queda expuesto. Para la actividad NoSQL Backup Strategy desarrollamos StockSafe, una aplicación web que registra productos y movimientos de almacén, y que además protege sus documentos mediante respaldos cifrados y recuperación controlada.

En este artículo explicaré el funcionamiento de StockSafe, por qué utilizamos MongoDB Atlas y cómo implementamos una estrategia de respaldos NoSQL. El enfoque principal no es solo almacenar información, sino poder recuperarla después de un incidente.

1. El problema y la solución

En un inventario se necesitan productos actualizados, cantidades disponibles y un historial de entradas y salidas. Una eliminación accidental o un error en los datos puede afectar la operación. StockSafe combina la gestión cotidiana del stock con un módulo de respaldo y restauración.

El sistema ofrece:

  • Inicio de sesión y perfiles de administrador y operador.
  • Dashboard con indicadores y alertas por stock mínimo.
  • Registro y edición de productos con código SKU, categoría, precio y existencias.
  • Entradas y salidas de inventario, con validación para evitar stock negativo.
  • Historial de movimientos y exportación de productos a CSV.
  • Generación, descarga, importación y restauración de archivos cifrados .ssb.

[INSERTAR CAPTURA 1: Dashboard principal de StockSafe]

2. Arquitectura y tecnologías

La aplicación se desarrolló en Python y FastAPI, utilizando plantillas Jinja2, JavaScript y estilos web para la interfaz. La información operativa reside en MongoDB Atlas, un servicio administrado de base de datos NoSQL. Render aloja la aplicación pública y GitHub Actions ejecuta las pruebas y tareas automatizadas.

El flujo general es:

Usuario -> StockSafe / FastAPI -> MongoDB Atlas | +-> Respaldos cifrados (.ssb) | +-> Render y GitHub Actions

[INSERTAR CAPTURA 2: Vista de colecciones en MongoDB Atlas]

3. Modelo documental de MongoDB

StockSafe trabaja principalmente con dos colecciones operativas:

products guarda los productos, incluyendo SKU, nombre, categoría, precio expresado en céntimos, stock actual, stock mínimo y estado activo.

movements registra cada entrada o salida, con referencia al producto, cantidad, motivo, usuario responsable, fecha y stock resultante.

Esta estructura permite consultar existencias y conservar trazabilidad. Por ejemplo, al registrar una salida de dos unidades, el sistema reduce el stock y guarda el movimiento correspondiente. En las pruebas del proyecto registramos una laptop con diez unidades y confirmamos que, después de una salida de dos, el stock mostrado era ocho.

El código utiliza una actualización condicional de MongoDB para impedir que una salida deje cantidades negativas.

[INSERTAR CAPTURA 3: Productos y movimiento de salida con stock final]

4. Nuestra estrategia de respaldo NoSQL

Para esta entrega implementamos un respaldo lógico a nivel de aplicación, no un mongodump de todo el clúster. El respaldo captura específicamente las colecciones products y movements; no incorpora usuarios ni contraseñas.

El procedimiento interno es:

  1. Consultar los documentos de ambas colecciones.
  2. Serializarlos utilizando MongoDB Extended JSON para conservar tipos como ObjectId y fechas.
  3. Comprimir los datos con GZIP.
  4. Derivar una clave desde una frase privada mediante Scrypt.
  5. Cifrar el contenido con AES-256-GCM, utilizando una sal y un nonce aleatorios.
  6. Guardar el resultado en un archivo propio con extensión .ssb.

Esta combinación evita que el contenido de un archivo pueda leerse directamente sin su clave. AES-GCM también permite detectar alteraciones de los datos cifrados.

Desde la interfaz, los respaldos manuales se almacenan en una base separada llamada stocksafe_vault usando GridFS, dentro del mismo clúster. Esta copia ayuda ante errores de la aplicación, pero por sí sola no protege ante la pérdida completa del clúster.

[INSERTAR CAPTURA 4: Pantalla Respaldos y recuperación con archivo .ssb]

5. Respaldo externo y recuperación

Para mejorar la protección incorporamos una segunda ubicación: GitHub Actions conserva un archivo .ssb cifrado como artifact fuera de MongoDB Atlas. El workflow puede ejecutarse manualmente y está programado diariamente a las 07:17 hora de Perú (12:17 UTC), con retención configurada de 30 días.

La recuperación se realiza desde el módulo de respaldos, utilizando una copia existente o importando un archivo externo. Antes de reemplazar productos y movimientos, StockSafe genera una copia preventiva del estado actual. Si ocurre un problema, el sistema intenta recuperar ese estado anterior.

La restauración exige confirmación administrativa. En esta edición académica no se utiliza una transacción ACID multidocumento, por lo que las demostraciones deben realizarse sin operaciones simultáneas sobre el inventario.

[INSERTAR CAPTURA 5: Archivo descargado o restauración comprobada]

6. Seguridad y pruebas

Las sesiones de usuario están protegidas; las contraseñas de acceso se almacenan mediante Argon2, los formularios usan protección CSRF y el módulo de restauración es exclusivo para administradores.

Las claves de MongoDB, cifrado y automatización se administran mediante variables de entorno y secretos de GitHub, no dentro del repositorio público.

En GitHub Actions, la ejecución de pruebas y despliegue terminó correctamente con 8 pruebas aprobadas, cubriendo inventario, control de acceso, cifrado, restauración y autorización del respaldo automatizado. También verificamos una ejecución exitosa del workflow de backup con un artifact externo llamado stocksafe-nosql-43669394336.

[INSERTAR CAPTURA 6: GitHub Actions, pruebas en verde y artifact del respaldo]

7. Resultados y limitaciones

StockSafe permite vincular una operación cotidiana, como registrar una salida de stock, con mecanismos de recuperación ante errores. La prueba de ejecución automatizada confirma la creación de una copia externa cifrada; las pruebas automatizadas comprueban las funciones de restauración.

Esta versión tiene límites deliberados: el respaldo cubre solo dos colecciones, admite hasta 10 000 documentos por colección, el archivo cifrado tiene un límite de 25 MB y los artifacts se retienen 30 días. Para un sistema empresarial sería necesario agregar retención prolongada, monitoreo, restauración transaccional y ensayos periódicos de recuperación ante desastres.

8. Conclusiones

El proyecto nos permitió entender que una base de datos NoSQL requiere tanto una buena estructura documental como una estrategia de recuperación. MongoDB Atlas facilita el almacenamiento, mientras que StockSafe agrega copias cifradas y un procedimiento de restauración aplicable a datos reales de inventario.

La lección más importante es que hacer un respaldo no basta: debemos protegerlo, conservarlo fuera de la base de datos y verificar que pueda recuperarse.

Enlaces del proyecto

Referencias