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:
Top comments (0)