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

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 SACRA360.

El problema real

No estábamos buscando un problema de ingeniería cool. 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


• Cero 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 del proyecto 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 nuestro 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 nos gustó implementar. El flujo es:

1. El usuario sube una imagen escaneada de un libro sacramental


2. El archivo va a S3
   


3. Un endpoint del backend lo envía a AWS Textract
   


4. Textract extrae el texto automáticamente


5. 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 usa AWS Lambda. No necesitas un servidor corriendo 24/7 para generar un PDF cuando alguien lo pide. Lambda se activa, genera el certificado, lo guarda en S3 bajo /generated, y listo. Sin costos de servidor idle.

El frontend en S3 + 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. Simple y funciona.

Stack completo

La decisión más debatida: ¿serverless o 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 moda. Lambda es increíble para tareas puntuales sin estado. Pero si pones toda tu lógica de negocio en funciones, terminas con un sistema difícil de debuggear, con cold starts en momentos inconvenientes, y con conexiones a base de datos que se complican innecesariamente.

Los costos (sí, hicimos el cálculo)

Para el MVP con configuraciones de bajo consumo:

Los servicios que más pesan:

• 
  RDS PostgreSQL: $55.59/mes — la base de datos es cara, pero es el core del sistema


• 
  QuickSight: $18/mes — dashboards


• 
  EC2: $3.80/mes — instancia pequeña para el MVP

Lambda, S3 y CloudWatch prácticamente gratis en este volumen. Cuando el sistema escale y el OCR procese miles de documentos, la ecuación cambia.

Lo que viene

El MVP valida la idea, pero hay mucho por construir:

• 
  AWS OpenSearch para búsquedas full-text sobre el texto extraído por OCR


• Autenticación con roles granulares: párroco, administrador, consultor, digitalizador


• Auditoría completa de acciones


• Integración entre parroquias distintas


• Migración masiva de documentos históricos

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.

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

El código está en GitHub:

• Backend


• Frontend


• Microservicio de Certificados


• Microservicio de Reportes

Proyecto académico — SIS-331 Computación en la Nube, Universidad Católica Boliviana "San Pablo", La Paz, Bolivia.


*Equipo GatoByte:

• Ivonne Colque


• Dilan Mamani


• Tania Pérez


• Ignacio Retamozo


• Adriana Rocha
  *