Digitalizando 200 años de historia: Sacra-360, un sistema para registros sacramentales

Tania Morelia Pérez Dick — Tue, 02 Jun 2026 18:29:47 +0000

Hay una caja en el sótano de casi cada parroquia de Bolivia. Dentro hay libros viejos, algunos con décadas de humedad encima, donde están escritos a mano los bautizos, matrimonios y confirmaciones de miles de personas. ¿Tu bisabuela nació en 1932 y necesitas probarlo? Alguien va a tener que buscar en esa caja.

Eso fue lo que nos motivó a construir Sacra-360.

Tabla de contenidos

El problema real
La solución: arquitectura híbrida
Stack completo
La decisión más debatida: serverless vs. servicios administrados
La seguridad no fue un añadido, fue la mitad del proyecto
Reflexión final

El problema real

No estábamos buscando un problema de ingeniería interesante. El problema simplemente existe: la Iglesia Católica en Bolivia maneja una cantidad enorme de documentos históricos completamente en físico. Cuando alguien necesita un certificado de bautizo, el proceso es:

llamar a la parroquia → buscar el libro correcto → encontrar la página → transcribir a mano → enviar el papel

Y eso si el libro no se humedeció, no se perdió, o si la parroquia no está cerrada ese día.

Los problemas concretos que teníamos que resolver:

Más de 100,000 registros que necesitan búsqueda rápida
Documentos físicos que se deterioran con el tiempo
Sin integración entre parroquias distintas
Parroquias con fotos y scans de libros históricos que no sirven de nada sin una forma de consultarlos

La solución: arquitectura híbrida

Lo más interesante técnicamente es que no quisimos atarnos a un solo proveedor ni a un solo modelo de despliegue. Usamos servicios administrados (Vercel, Render, Neon) para todo lo persistente, y recurrimos a AWS únicamente donde tenía más sentido: OCR, generación de certificados y almacenamiento de archivos.

El backend vive en Render

El backend principal (Node.js) corre como un web service en Render. Ahí vive el backend persistente que maneja autenticación, gestión de usuarios, sacramentos, personas y parroquias, junto con el microservicio de generación de reportes PDF/Excel.

¿Por qué Render y no serverless para todo? Porque necesitábamos conexiones constantes a base de datos, lógica de negocio centralizada, y múltiples módulos activos al mismo tiempo. Poner todo eso en funciones serverless hubiera aumentado la complejidad de mantenimiento sin beneficio real para este caso de uso.

La base de datos en Neon

Nada sofisticado aquí, pero no tenía que serlo. Neon nos da PostgreSQL completamente administrado, con escalado automático y una capa gratuita que nos alcanzó de sobra para el MVP. Ya teníamos experiencia con Postgres en el equipo, así que no perdimos tiempo migrando el modelo de datos.

El OCR es donde se pone interesante

Esta es la parte que más disfrutamos implementar. El flujo es:

El usuario sube una imagen escaneada de un libro sacramental
El archivo va a S3
Un endpoint del backend lo envía a AWS Textract
Textract extrae el texto automáticamente
El sistema parsea y retorna datos estructurados: nombre, fecha, parroquia, número de registro, etc.

Probamos con una partida de bautismo real y este fue el resultado:

{
  "datosDetectados": {
    "fecha_sacramento": "12/04/2020",
    "foja": "45",
    "numero": "123",
    "nombre": "Juan Diego Pérez Lopez",
    "parroquia": "SAN JUAN BAUTISTA"
  }
}

Eso fue extraído automáticamente de una imagen escaneada. Lo que antes requería transcripción manual ahora toma segundos.

Lambda para lo que es puntual

La generación de certificados PDF corre en AWS Lambda. No tiene sentido mantener un servidor activo las 24 horas para generar un PDF cuando alguien lo solicita. Lambda se activa, genera el certificado, lo guarda en S3 bajo /generated, y listo. Sin costos de servidor idle.

El frontend en Vercel con CI/CD automático

El frontend es React + Vite, y se despliega automáticamente a Vercel con cada push al repositorio. Vercel se encarga del build, el CDN y los previews por cada pull request; para el backend en Render usamos GitHub Actions para las validaciones previas al deploy.

Stack completo

Servicio	Rol en el proyecto
React + Vite	Frontend
Vercel	Hosting y CI/CD del frontend
Node.js	Backend principal + microservicio de reportes
Render	Hosting del backend (Node.js)
Neon (PostgreSQL)	Base de datos principal
AWS S3	Documentos históricos y certificados generados
AWS Lambda	Generación de certificados PDF bajo demanda
AWS Textract	OCR automático sobre documentos escaneados
GitHub Actions	CI/CD y validaciones del backend
Docker	Estandarización del entorno de desarrollo
bcrypt	Hashing de contraseñas
Cloudflare Turnstile	CAPTCHA en el login
OWASP ZAP	Escaneo de vulnerabilidades (auditoría, no producción)

La decisión más debatida: serverless vs. servicios administrados

Al final llegamos a un principio claro:

Serverless para lo eventual — generación de PDFs (Lambda), procesamiento OCR (Textract)
Servicios administrados para lo persistente — backend en Render, base de datos en Neon, frontend en Vercel

La clave fue no enamorarse de una arquitectura por convención. Lambda y Textract funcionan muy bien para tareas puntuales sin estado. Pero si pones toda la lógica de negocio en funciones, terminas con un sistema difícil de depurar, con cold starts en momentos inconvenientes, y con conexiones a base de datos que se complican sin necesidad — para eso preferimos un backend persistente en Render conectado a Neon.

La seguridad no fue un añadido, fue la mitad del proyecto

Digitalizar los libros no sirve de mucho si cualquier cuenta puede editar los registros de otra parroquia, o si una contraseña débil termina exponiendo datos personales y canónicos de miles de personas. La versión original del sistema tenía problemas serios:

Solo existían dos roles, y ambos con privilegios elevados
No había políticas de contraseñas robustas
El control de accesos no estaba estructurado
No existía ningún mecanismo de auditoría ni trazabilidad

La reingeniería de seguridad terminó siendo, en tiempo y esfuerzo, tan grande como la parte de arquitectura.

Ver el detalle completo: roles, contraseñas, auditoría y el escaneo OWASP ZAP

Identidad y roles

Reemplazamos los dos roles originales por seis roles diferenciados, cada uno con permisos granulares validados tanto en frontend como en backend:

Rol	Alcance
Administrador Diocesano	Gestión global a nivel diócesis
Párroco	Gestión de su propia parroquia
Digitador	Registro y carga de sacramentos
Secretario Parroquial	Atención y emisión de certificados
Auditor	Solo lectura sobre logs y eventos de seguridad
OSI	Administración técnica y de seguridad del sistema

El correo institucional pasó a ser el identificador único de cada usuario, así evitamos cuentas duplicadas o ambiguas entre parroquias.

Contraseñas y autenticación

Las contraseñas se almacenan con bcrypt, y sobre eso agregamos políticas configurables de complejidad, longitud, tiempo de vida útil e historial de reutilización, para que nadie pueda volver a usar una contraseña que ya quedó comprometida. Además sumamos:

Verificación en dos pasos (2FA)
CAPTCHA con Cloudflare Turnstile
Bloqueo automático después de varios intentos fallidos

Auditoría y análisis de riesgos

Construimos dos módulos de auditoría independientes que registran en detalle las operaciones sobre los datos y los eventos de seguridad del sistema, algo que antes no existía en absoluto. A eso se suma un módulo de análisis de riesgos, con una matriz de riesgo inherente y residual integrada directamente en la plataforma en vez de vivir en una hoja de cálculo aparte.

Un escaneo real, no solo buenas intenciones

Antes de dar el proyecto por cerrado corrimos un escaneo de vulnerabilidades con OWASP ZAP, que detectó 11 alertas iniciales. Corregimos las más críticas configurando cabeceras HTTP de seguridad. Todo el diseño se guió por los principios de OWASP: mínimo privilegio, seguridad por defecto, mediación completa, economía del mecanismo y mecanismo menos común.

Reflexión final

Este proyecto nos recordó que la tecnología cloud más valiosa no es la más sofisticada, sino la que resuelve problemas reales. No construimos SACRA360 para usar los últimos servicios de AWS. Lo construimos porque hay registros históricos en cajas de sótano que podrían perderse para siempre, y eso nos pareció un problema que valía la pena atacar.

Si tienen un proyecto similar o les interesa el tema de digitalización de archivos históricos con OCR, con gusto conversamos en los comentarios.

El código está en GitHub:

Proyecto académico — SIS-325 Ética y Seguridad de Sistemas, Universidad Católica Boliviana "San Pablo", La Paz, Bolivia.

Equipo GatoByte:

DEV Community: Tania Morelia Pérez Dick