Billin es una plataforma SaaS de facturación y contabilidad utilizada por decenas de miles de autónomos y pymes en España. Cuando tu negocio depende de emitir facturas a tiempo, de cuadrar impuestos trimestrales y de mantener la contabilidad al día, la infraestructura que soporta ese servicio no puede fallar. Ni un segundo.
Ese era el contexto cuando Billin contactó con NERVICO. Su plataforma funcionaba, pero la infraestructura que la sostenía empezaba a mostrar señales de fatiga. Tiempos de respuesta que crecían, ventanas de mantenimiento que frustraban a usuarios, y una arquitectura que dificultaba alcanzar los estándares de seguridad que el sector fintech exige.
El desafío
Una plataforma que no podía parar
Billin no es una aplicación de productividad que puedes reiniciar un domingo por la noche. Es la herramienta con la que miles de negocios generan facturas, calculan impuestos y presentan informes contables. Cualquier minuto de indisponibilidad tiene un impacto directo en la operativa de sus usuarios.
La infraestructura original había sido construida con decisiones razonables para el momento, pero el crecimiento de la base de usuarios estaba exponiendo limitaciones:
- Tiempos de respuesta crecientes: A medida que el volumen de datos aumentaba, las consultas a la API se ralentizaban. Las operaciones que antes tardaban 200ms empezaban a superar los 500ms en horarios pico.
- Ventanas de mantenimiento obligatorias: Cada actualización significativa requería programar un periodo de inactividad, normalmente de madrugada. Aunque planificado, esto generaba incertidumbre y frustración entre los usuarios.
- Seguridad adecuada pero insuficiente para fintech: La seguridad existente cubría lo básico, pero Billin necesitaba avanzar hacia estándares más estrictos. Los datos financieros de miles de empresas requieren un nivel de protección que va más allá del cifrado convencional.
- Escalado manual y costoso: La infraestructura no se adaptaba automáticamente a picos de demanda. En periodos de alta actividad, como cierres trimestrales de IVA, el equipo tenía que intervenir manualmente para aumentar capacidad.
El reto era claro: modernizar toda la infraestructura sin interrumpir el servicio ni un instante.
La solución
Migración sin downtime con despliegues blue-green
El principio rector del proyecto fue sencillo: los usuarios de Billin no debían notar nada. Ni una petición fallida, ni un error 503, ni un “estamos en mantenimiento”. La estrategia de despliegue blue-green nos permitió conseguirlo.
El enfoque blue-green funciona manteniendo dos entornos idénticos en paralelo. Mientras el entorno “blue” sigue sirviendo tráfico real, el entorno “green” se configura y prueba con la nueva infraestructura. Una vez validado, el tráfico se redirige al nuevo entorno de forma instantánea. Si algo falla, el rollback es igual de inmediato.
Contenedorización con ECS Fargate
Migramos la aplicación a una arquitectura basada en contenedores usando Amazon ECS con Fargate. Esta decisión eliminó la necesidad de gestionar servidores directamente y aportó varias ventajas:
- Escalado automático: Los contenedores se crean y destruyen en función de la demanda real, no de estimaciones manuales.
- Aislamiento de fallos: Un problema en un componente no arrastra al resto del sistema.
- Despliegues consistentes: El mismo contenedor que pasa los tests en staging es el que se ejecuta en producción. Sin sorpresas.
Optimización de base de datos
La base de datos era uno de los principales cuellos de botella. Migramos a Amazon Aurora PostgreSQL, que ofrece rendimiento significativamente superior al PostgreSQL estándar en RDS, con read replicas dedicadas para las consultas de reporting.
Esta separación fue clave: las operaciones transaccionales (crear facturas, registrar pagos) ya no competían por recursos con las consultas analíticas (informes trimestrales, dashboards de facturación). El resultado fue una reducción drástica en los tiempos de respuesta durante los picos de uso.
Seguridad de grado financiero
Para datos financieros, la seguridad no es una capa que se añade al final. Es una decisión arquitectónica que afecta a cada componente. Implementamos:
- Cifrado en reposo con AWS KMS: Todos los datos almacenados, incluidas las copias de seguridad, están cifrados con claves gestionadas por KMS.
- Cifrado en tránsito con TLS 1.3: Todas las comunicaciones, tanto internas como externas, utilizan la versión más reciente del protocolo TLS.
- WAF (Web Application Firewall): Protección contra ataques comunes como inyección SQL, XSS y DDoS a nivel de aplicación.
- Aislamiento de red con VPC: Cada componente vive en su propia subred, con reglas de acceso estrictas. La base de datos, por ejemplo, no es accesible desde internet bajo ninguna circunstancia.
Estos controles, combinados con políticas de acceso basadas en roles (IAM) y registro detallado de actividad (CloudTrail), dejaron la infraestructura preparada para una auditoría de cumplimiento SOC 2.
Monitorización y recuperación ante desastres
Configuramos un sistema de monitorización integral con Amazon CloudWatch que incluye:
- Dashboards personalizados con métricas de negocio: tiempos de respuesta por endpoint, tasa de errores, uso de CPU y memoria por servicio.
- Alertas automatizadas que notifican al equipo antes de que un problema afecte a los usuarios.
- Plan de backup y recuperación: Copias de seguridad automáticas cada hora con capacidad de restauración en minutos, no en horas.
- Pipeline CI/CD que permite despliegues sin downtime de forma continua, eliminando la necesidad de ventanas de mantenimiento futuras.
Resultados
La migración se completó sin un solo segundo de indisponibilidad. Los números hablan por sí solos:
| Métrica | Antes | Después |
|---|---|---|
| Downtime durante migración | N/A | 0 segundos |
| Tiempo medio de respuesta API | ~500ms en pico | ~200ms en pico (-60%) |
| Costes de infraestructura mensuales | Base | -35% respecto a la base |
| Frecuencia de despliegue | Semanal (con downtime) | Diaria (sin downtime) |
| Tiempo medio de recuperación (MTTR) | Horas | Minutos |
| Preparación SOC 2 | Parcial | Controles implementados |
El ahorro del 35% en costes puede parecer contradictorio cuando se mejora la infraestructura, pero tiene una explicación directa: los contenedores con escalado automático consumen solo los recursos necesarios en cada momento, frente a la sobreprovisionamiento permanente que requería la arquitectura anterior.
Lecciones aprendidas
Los despliegues blue-green no son opcionales en SaaS
Cualquier plataforma SaaS que maneje datos críticos de negocio necesita la capacidad de desplegar sin downtime y hacer rollback instantáneo. No es un lujo técnico. Es un requisito básico de operación profesional.
Seguridad y rendimiento van de la mano
Existe la percepción de que añadir capas de seguridad penaliza el rendimiento. En este caso ocurrió lo contrario: la reestructuración que exigía la seguridad (aislamiento de componentes, separación de responsabilidades, cifrado gestionado) resultó en una arquitectura más limpia y más rápida.
Los datos financieros exigen defensa en profundidad
No basta con un firewall perimetral. La seguridad de datos financieros requiere protección en cada capa: red, aplicación, almacenamiento y acceso. Si un atacante supera una barrera, la siguiente debe detenerlo. Este enfoque de defensa en profundidad es lo que diferencia la seguridad real de la seguridad aparente.
Si tu plataforma SaaS enfrenta desafíos similares de escalabilidad, seguridad o modernización de infraestructura, podemos ayudarte a evaluar opciones y definir un plan de acción. Solicita una auditoría gratuita o consulta nuestra guía de arquitectura AWS para startups para entender las decisiones clave.