Case Study
MagicMemories OS v2
Theme Park Photo Platform โ From Monolith to Microservices
Rebuilding the operating system behind the world's largest theme park photo company โ millions of photos daily, zero room for error.

The Challenge
Legacy monolith hitting its limits
The existing system processed millions of photos daily across theme parks worldwide, but peak-hour delays, mounting cloud costs, and deployment anxiety were slowing the business down.
Wildly different scaling needs
A roller coaster produces 20+ photos in 3 seconds. A family browsing the storefront spends 15 minutes. These can't live in the same scaling model.
Global operations across time zones
Theme parks in Orlando, Tokyo, and Gold Coast don't share peak hours. The system needed to handle rolling traffic spikes 24/7 with data residency compliance.
The Solution
A ground-up rebuild: event-driven microservices designed for real-time photo processing at global scale.
Event-Driven Architecture
Each photo flows through capture โ processing โ facial recognition โ matching โ storefront, with each stage as an independent service communicating via events.
Kubernetes Auto-Scaling
Services scale to zero during off-hours and spin up ahead of park opening times. No more paying for infrastructure handling zero traffic at 2 AM.
Multi-Region Deployment
Photos stay in the region they were captured โ reducing latency and complying with data residency requirements across continents.
Domain-Driven Design
Service boundaries follow business domains (capture, matching, storefront, operations) โ not technical layers. Everything clicked once we got this right.
Distributed Tracing
A single photo's journey touches 6+ services. OpenTelemetry-powered observability makes debugging across the pipeline straightforward.
.NET Core + Azure
Modern .NET Core services running on Azure Kubernetes Service with Terraform-managed infrastructure for repeatable deployments.
My Role
Platform Architecture
Designed the entire OS v2 architecture from scratch โ service boundaries, event schemas, data flow, and infrastructure topology for multi-region deployment.
Photo Processing Pipeline
Built the real-time pipeline handling millions of photos daily: capture ingestion, image processing, facial recognition matching, and storefront delivery.
Cloud Cost Optimization
Replaced oversized always-on VMs with auto-scaling Kubernetes pods. Significant cloud cost reduction while handling higher peak loads.
Data Migration
Migrated years of customer data, purchase history, and photo archives from the legacy system โ while keeping both systems running simultaneously.
Results
Shipped to theme parks worldwide with measurable impact.
Millions of Photos/Day
Processed across theme parks worldwide with sub-second latency from capture to storefront.
Global Scale
Multi-region deployment serving parks in the US, Japan, and Australia โ handling rolling peaks across time zones.
Cloud Costs Down
Auto-scaling replaced over-provisioned VMs. Zero-traffic off-hours now cost nearly nothing.
Zero-Downtime Migration
Parks worldwide switched from legacy to OS v2 with minimal disruption to operations.
50+ Pods Auto-Scaling
Processing pods spin up at 9 AM park time, handle the morning rush, then quietly scale back down.
Ship with Confidence
Engineers deploy features without fearing they'll break the photo pipeline. Observability + CI/CD changed the culture.
Hard Lessons Learned
Event ordering matters more than you think
"Photo processed" sometimes arrived before "photo uploaded" was confirmed. We built proper event ordering and idempotency โ after weeks of debugging.
Observability is not optional
We should have set up distributed tracing on day one, not month three. With 10+ services, you can't fix what you can't see.
Domain boundaries are everything
Our first attempt followed technical lines (API, processing, database). Wrong. The second attempt followed business domains. Everything clicked.
Data migration is a project in itself
Years of customer data, purchase history, and photo archives. Migrating while keeping both systems running was harder than building the new platform.
Interested in working together?
I help companies rebuild legacy systems into modern, scalable platforms โ without breaking what's already working.