Disney Parks
An administration platform for tens of millions of park visitors, rebuilt in the cloud beside a legacy system nobody was allowed to read.
Stack
- Go
- Node.js
- AWS Lambda
- Amazon ECS
- Amazon Kinesis
- Apache Kafka
- MongoDB
- Amazon Aurora
Problem
The core park administration platform ran on a large on-premises legacy system whose bottlenecks had stopped being a technical inconvenience and become a business constraint. It stood behind tens of millions of annual park visitors, which meant the cost of a bad architectural decision compounded quietly for years. Two facts shaped every decision that followed. The legacy system could not be switched off — it had to keep running in production, beside whatever replaced it, for years. And we had no access to its source code. It was not a system to be refactored; it was a black box with a business depending on it. Meanwhile each new frontend client spoke directly to a widening set of backends, so every new surface multiplied the authentication and permission logic that had to be written, reviewed, and kept correct.
Approach
I architected the long-term modernization as an incremental migration to a cloud-native AWS platform, delivered quarterly, with both environments coexisting throughout. The new ecosystem grew to 85+ cloud-native microservices, split across AWS Lambda and Amazon ECS — each workload placed by scalability, latency, operational cost, and how much maintenance it would still demand in five years, rather than by a blanket serverless policy. API composition was centralized behind a high-concurrency Node.js Backend-for-Frontend, which became the single place where token authentication and granular permission validation were enforced: one implementation to audit rather than one per client. Event-driven integration through Kinesis, Kafka, RabbitMQ, SNS, and SQS connected the new services both to real-time park attraction sensors and to the legacy estate. Persistence went to MongoDB sharded clusters, Aurora, and RDS by workload shape.
The tradeoff
A BFF is a shared dependency, and shared dependencies become coupling points. Every frontend team now waits on one layer. We accepted that cost deliberately: the alternative — permission logic duplicated across every client — is the kind of mistake that stays invisible until it becomes a security incident. Centralizing it made the risk one team's explicit responsibility, which is the only form of risk that ever gets managed. A diffuse risk is just a risk nobody owns.
Impact
85+ cloud-native microservices · auth centralized into one auditable layer
- 85+ cloud-native microservices designed and governed, standing behind tens of millions of annual park visitors
- Incremental migration from a large on-premises legacy system to AWS, both environments coexisting across a multi-year program
- Authentication, authorization, and request composition centralized into a single auditable Node.js BFF, across dozens of backend services
- 85+ AWS Lambda and Amazon ECS services placed by scalability, latency, cost, and maintainability rather than by policy
- Event-driven integration with real-time park attraction sensors and legacy enterprise platforms — Kinesis, Kafka, RabbitMQ, SNS, SQS
- Fault-tolerant patterns and automated testing made design-review requirements, enabling continuous quarterly releases
- AI-assisted engineering workflows introduced under strict architectural guidelines
What I learned
You cannot refactor what you are not allowed to read, and for three years the thing we had to integrate with was a system whose source we were never given. The honest response is not to guess. It is to model the boundary explicitly and treat every assumption about legacy behaviour as a hypothesis with an owner and a test. The integration seam ended up the most carefully documented part of the platform, and it was the part that never surprised us. Where we got hurt was in the services we thought we knew well.