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.
Reemplazamos los dos roles originales por seis roles diferenciados, cada uno con permisos granulares validados tanto en frontend como en backend: El correo institucional pasó a ser el identificador único de cada usuario, así evitamos cuentas duplicadas o ambiguas entre parroquias. 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: 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. 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.Ver el detalle completo: roles, contraseñas, auditoría y el escaneo OWASP ZAP
Identidad y roles
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
Contraseñas y autenticación
Auditoría y análisis de riesgos
Un escaneo real, no solo buenas intenciones
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:
Top comments (0)