Mozrest conecta restaurantes con plataformas de reservas en toda Europa. Su tecnología actúa como puente entre los sistemas de gestión de los restaurantes y las principales plataformas de reservas online, sincronizando disponibilidad, reservas y datos de clientes en tiempo real.
Cuando el volumen de reservas procesadas empezó a crecer de forma sostenida, la infraestructura AWS que habían construido en sus primeras etapas empezó a mostrar sus límites. No era un problema de concepto. Era un problema de escala.
Este caso describe cómo rediseñamos su arquitectura cloud para soportar el crecimiento sin disparar los costes.
El desafío
La plataforma de Mozrest había crecido de forma orgánica. Lo que empezó como una aplicación monolítica sobre EC2 funcionaba bien con decenas de restaurantes. Pero con cientos de restaurantes activos en varios países europeos y miles de reservas diarias, los problemas se acumulaban.
Infraestructura frágil
La aplicación principal corría en instancias EC2 gestionadas manualmente. No había redundancia multi-AZ, lo que significaba que un fallo en una zona de disponibilidad podía dejar el servicio inoperativo. Para una plataforma de reservas, cada minuto sin servicio son reservas perdidas y restaurantes descontentos.
El uptime rondaba el 99.5%. Parece un número alto, pero equivale a más de 43 horas de indisponibilidad al año. En hostelería, donde las horas punta de reservas se concentran en franjas muy concretas, una caída en el momento equivocado tiene un impacto desproporcionado.
Costes fuera de control
La factura de AWS crecía más rápido que los ingresos. Instancias sobredimensionadas que corrían 24/7 sin ajustarse a la demanda real, volúmenes EBS huérfanos, transferencia de datos sin optimizar y ausencia total de Reserved Instances o Savings Plans. No había visibilidad de dónde se iba cada euro.
Despliegues manuales y arriesgados
Cada despliegue era un evento de alto riesgo. El proceso manual tardaba entre 2 y 3 horas, requería intervención directa en los servidores y no tenía rollback automatizado. Esto limitaba la frecuencia de despliegues y ralentizaba la capacidad del equipo de producto para iterar.
Base de datos como cuello de botella
La base de datos PostgreSQL corría en una instancia RDS gestionada manualmente, sin escalado automático y con backups configurados de forma básica. A medida que el volumen de datos crecía, las consultas se ralentizaban y la falta de una capa de caché obligaba a cada petición a golpear directamente la base de datos.
La solución
Realizamos una auditoría completa de la infraestructura antes de tocar nada. Esto es un principio que aplicamos siempre: antes de migrar, hay que entender exactamente qué hay, qué cuesta y qué duele. La auditoría reveló que el 40% del gasto mensual se podía eliminar sin cambiar la arquitectura. Pero optimizar costes en una arquitectura frágil no tiene sentido a largo plazo. Decidimos rediseñar.
De monolito EC2 a microservicios en ECS Fargate
Migramos la aplicación monolítica a contenedores Docker orquestados con ECS Fargate. La decisión de usar Fargate en lugar de ECS sobre EC2 fue deliberada: elimina la necesidad de gestionar instancias subyacentes, reduce la carga operativa y permite escalar cada servicio de forma independiente.
La migración no fue un big bang. Extrajimos los servicios uno a uno, empezando por los más independientes y con menor riesgo. El monolito y los nuevos microservicios coexistieron durante semanas hasta completar la transición. Este enfoque incremental redujo el riesgo y permitió al equipo de Mozrest seguir desarrollando funcionalidades durante la migración.
Aurora PostgreSQL Serverless v2
Sustituimos la instancia RDS autogestionada por Aurora PostgreSQL Serverless v2. Las ventajas fueron inmediatas:
- Escalado automático: Aurora ajusta la capacidad de computación según la demanda. Durante las horas punta de reservas, escala hacia arriba. En las horas valle, escala hacia abajo. Sin intervención manual.
- Alta disponibilidad nativa: Réplicas multi-AZ automáticas con failover en menos de 30 segundos.
- Backups continuos: Point-in-time recovery con retención de 35 días, sin impacto en rendimiento.
Capa de caché con ElastiCache (Redis)
Implementamos ElastiCache con Redis para dos funciones principales: gestión de sesiones y caché de datos frecuentes. Las consultas de disponibilidad de restaurantes, que antes golpeaban la base de datos en cada petición, ahora se sirven desde caché con TTLs ajustados al ritmo de actualización real.
El resultado fue una reducción del 70% en las consultas directas a la base de datos y tiempos de respuesta de la API significativamente menores.
CDN y activos estáticos
Configuramos CloudFront como CDN delante de S3 para servir todos los activos estáticos. Esto redujo la latencia para los usuarios finales en toda Europa y descargó tráfico de los servidores de aplicación.
CI/CD con GitHub Actions y CodeDeploy
Diseñamos un pipeline de CI/CD completo:
- GitHub Actions para ejecutar tests, construir imágenes Docker y validar la infraestructura.
- Amazon ECR como registro de imágenes de contenedores.
- CodeDeploy con despliegues blue/green para actualizaciones sin downtime.
- Rollback automático si las health checks fallan tras el despliegue.
El equipo de Mozrest pasó de desplegar con miedo a desplegar varias veces al día con confianza.
Infraestructura como código con Terraform
Toda la infraestructura se codificó en Terraform. Cada recurso de AWS, desde los clusters de ECS hasta las políticas de IAM, quedó versionado en Git. Esto permitió:
- Reproducir el entorno completo en minutos.
- Revisar cambios de infraestructura con el mismo proceso de code review que el código de aplicación.
- Mantener consistencia entre entornos de staging y producción.
Optimización de costes
Más allá del rediseño arquitectónico, aplicamos optimizaciones específicas de costes:
- Savings Plans para compute Fargate con compromiso de 1 año, reduciendo el coste por hora de computación un 30%.
- S3 Lifecycle Policies para mover datos antiguos a S3 Glacier automáticamente.
- VPC Endpoints para eliminar costes de transferencia de datos entre servicios AWS que antes pasaban por la internet pública.
- Right-sizing continuo con AWS Compute Optimizer para ajustar los recursos de cada tarea Fargate al consumo real.
Resultados
Los números hablan por sí solos:
- 99.99% de uptime, frente al 99.5% anterior. Menos de 53 minutos de indisponibilidad al año, con failover automático multi-AZ.
- 40% de reducción en costes mensuales de AWS, combinando la migración a Fargate, Aurora Serverless, Savings Plans y la eliminación de recursos infrautilizados.
- 3x de capacidad de throughput sin necesidad de infraestructura adicional. La plataforma puede procesar tres veces más reservas por segundo que antes de la migración.
- Despliegues en menos de 10 minutos, frente a las 2-3 horas anteriores. Con zero-downtime y rollback automático.
- Plan de disaster recovery completo, con RPO inferior a 5 minutos y RTO inferior a 30 minutos.
Lecciones aprendidas
Empieza por la auditoría de costes, no por la migración
La auditoría inicial nos permitió identificar ahorros inmediatos que financiaron parte de la migración. Más importante: nos dio un mapa preciso de la infraestructura existente, sus dependencias y sus puntos de dolor reales. Sin ese mapa, las decisiones de arquitectura habrían sido especulativas.
La migración a contenedores no tiene por qué ser todo o nada
El enfoque incremental, servicio a servicio, redujo el riesgo y permitió al equipo de Mozrest mantener su velocidad de desarrollo durante todo el proceso. No hubo un “día D” de migración. Hubo una transición gradual y controlada.
Invierte en infraestructura como código antes de escalar
Terraform nos permitió iterar sobre la arquitectura con la misma disciplina que sobre el código de aplicación. Cada cambio de infraestructura pasó por pull request, revisión y aprobación. Esto evitó configuraciones manuales que se pierden, se olvidan o se contradicen entre entornos.
La optimización de costes es un proceso continuo
Reducir la factura un 40% fue el resultado inicial. Pero el valor real está en haber establecido los procesos y herramientas para que el equipo de Mozrest mantenga esa disciplina de forma autónoma. AWS Budgets, Cost Explorer, Compute Optimizer y Savings Plans no son configuraciones de un día: son prácticas que requieren revisión periódica.
Si tu infraestructura AWS está creciendo más rápido que tu negocio, o si necesitas escalar sin multiplicar costes, podemos ayudarte. Solicita una auditoría gratuita para analizar tu situación actual y definir un plan de acción concreto.
Para más contexto sobre arquitectura AWS, consulta nuestra guía de arquitectura AWS para startups.