Disney Parks
Una plataforma de administración para decenas de millones de visitantes, reconstruida en la nube junto a un sistema legado que nadie tenía permitido leer.
Stack
- Go
- Node.js
- AWS Lambda
- Amazon ECS
- Amazon Kinesis
- Apache Kafka
- MongoDB
- Amazon Aurora
Problema
La plataforma central de administración de parques corría sobre un gran sistema legado on-premises cuyos cuellos de botella habían dejado de ser una molestia técnica para convertirse en una restricción del negocio. Detrás de ella había decenas de millones de visitantes anuales: el costo de una mala decisión arquitectónica se acumulaba en silencio durante años. Dos hechos moldearon todo lo que vino después. El sistema legado no se podía apagar — tenía que seguir en producción, junto a lo que fuera que lo reemplazara, durante años. Y no teníamos acceso a su código fuente. No era un sistema para refactorizar; era una caja negra con un negocio dependiendo de ella. Mientras tanto, cada cliente de frontend hablaba directamente con un conjunto creciente de backends, así que cada nueva superficie multiplicaba la lógica de autenticación y permisos que había que escribir, revisar y mantener correcta.
Enfoque
Diseñé la modernización de largo plazo como una migración incremental hacia una plataforma cloud-native en AWS, entregada por trimestres, con ambos entornos conviviendo todo el tiempo. El ecosistema nuevo creció hasta 85+ microservicios cloud-native, repartidos entre AWS Lambda y Amazon ECS: cada carga ubicada según escalabilidad, latencia, costo operativo y cuánto mantenimiento seguiría exigiendo dentro de cinco años, y no según una política serverless por defecto. La composición de APIs se centralizó detrás de un Backend-for-Frontend en Node.js de alta concurrencia, que se convirtió en el único lugar donde se aplicaban la autenticación por token y la validación granular de permisos: una implementación que auditar, en vez de una por cliente. La integración event-driven con Kinesis, Kafka, RabbitMQ, SNS y SQS conectó los servicios nuevos tanto con los sensores de atracciones en tiempo real como con el patrimonio legado. La persistencia fue a clústeres MongoDB con sharding, Aurora y RDS, según la forma de cada carga.
El compromiso
Un BFF es una dependencia compartida, y las dependencias compartidas se vuelven puntos de acoplamiento. Ahora cada equipo de frontend espera por una sola capa. Aceptamos ese costo de forma deliberada: la alternativa —lógica de permisos duplicada en cada cliente— es la clase de error que permanece invisible hasta que se convierte en un incidente de seguridad. Centralizarla hizo que el riesgo fuera la responsabilidad explícita de un equipo, que es la única forma de riesgo que llega a gestionarse. Un riesgo difuso es simplemente un riesgo del que nadie responde.
Impacto
85+ microservicios cloud-native · autenticación centralizada en una sola capa auditable
- 85+ microservicios cloud-native diseñados y gobernados, sosteniendo a decenas de millones de visitantes anuales
- Migración incremental de un gran sistema legado on-premises hacia AWS, con ambos entornos conviviendo durante un programa de varios años
- Autenticación, autorización y composición de peticiones centralizadas en un único BFF auditable en Node.js, sobre decenas de servicios backend
- 85+ servicios en AWS Lambda y Amazon ECS ubicados por escalabilidad, latencia, costo y mantenibilidad, y no por política
- Integración event-driven con los sensores de atracciones en tiempo real y con las plataformas legadas — Kinesis, Kafka, RabbitMQ, SNS, SQS
- Patrones tolerantes a fallos y pruebas automatizadas convertidos en requisito del design review, habilitando releases trimestrales continuos
- Flujos de ingeniería asistidos por IA introducidos bajo guías arquitectónicas estrictas
Lo que aprendí
No puedes refactorizar lo que no te dejan leer, y durante tres años aquello con lo que teníamos que integrarnos fue un sistema cuyo código nunca nos dieron. La respuesta honesta no es adivinar. Es modelar la frontera de forma explícita y tratar cada supuesto sobre el comportamiento del legado como una hipótesis con dueño y con prueba. La costura de integración terminó siendo la parte mejor documentada de la plataforma, y fue la parte que nunca nos sorprendió. Donde nos hicimos daño fue en los servicios que creíamos conocer bien.