Digitalizando 200 años de historia: Sacra-360, un sistema cloud 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.

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 en AWS

Lo más interesante técnicamente es que no quisimos ir full serverless ni full tradicional. Elegimos una arquitectura híbrida, y acá explicamos por qué.

El core vive en EC2

El backend principal (Node.js) corre en una instancia EC2. Tenemos un backend persistente que maneja autenticación, gestión de usuarios, sacramentos, personas y parroquias. También hay un microservicio separado para generación de reportes PDF/Excel.

¿Por qué EC2 y no Lambda 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 Lambda hubiera aumentado la complejidad de mantenimiento sin beneficio real para este caso de uso.

La base de datos en RDS PostgreSQL

Nada sofisticado aquí, pero no tenía que serlo. PostgreSQL administrado en AWS nos da integridad relacional, backups automáticos, y ya teníamos experiencia con Postgres en el equipo. Corriendo en db.t4g.micro para el MVP, con capacidad de escalar cuando sea necesario.

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 S3 con CI/CD automático

El frontend es React + Vite, y se despliega automáticamente a S3 con cada push al repositorio mediante GitHub Actions. El pipeline compila, configura credenciales AWS, y sube los archivos estáticos.

Stack completo

Servicio	Rol en el proyecto
AWS EC2	Backend Node.js + microservicio de reportes
AWS RDS PostgreSQL	Base de datos principal
AWS S3	Frontend estático, documentos históricos, certificados
AWS Lambda	Generación de certificados PDF bajo demanda
AWS Textract	OCR automático sobre documentos escaneados
AWS CloudWatch	Logs y monitoreo
AWS QuickSight	Dashboards y reportes visuales
GitHub Actions	CI/CD automático para el frontend
Docker	Estandarización del entorno de desarrollo
PM2 + systemd	Backend siempre activo en EC2

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

Al final llegamos a un principio claro:

Serverless para lo eventual — generación de PDFs, procesamiento OCR
Tradicional para lo persistente — backend principal, base de datos

La clave fue no enamorarse de una arquitectura por convención. Lambda funciona 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.

Los costos

Para el MVP con configuraciones de bajo consumo, la estimación usando AWS Pricing Calculator fue:


Costo mensual estimado	$78.22 USD
Costo anual estimado	$938.64 USD

Los servicios con mayor impacto:

RDS PostgreSQL: $55.59/mes — la base de datos es el componente más costoso, pero también el más crítico
QuickSight: $18/mes — dashboards y reportes
EC2: $3.80/mes — instancia pequeña para el MVP

Lambda, S3 y CloudWatch tienen un costo mínimo en este volumen. A medida que el sistema procese más documentos históricos vía OCR, esa proporción va a cambiar.

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-331 Computación en la Nube, Universidad Católica Boliviana "San Pablo", La Paz, Bolivia.

Equipo GatoByte:

DEV Community: Tania Morelia Pérez Dick