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.

MagicMemories OS v2

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.