When 150,000 tickets went on sale for The Odyssey in 70mm IMAX, they sold out almost instantly. But plans change, cancellations happen, and good seats randomly open up at odd hours.
To solve this, Andrew Baker from Temporal built IMAXXING: a service that monitors every 70mm IMAX showing across the US and alerts subscribers the moment great seats become available. What started as a fun weekend project quickly scaled, now over 9,000 users.
I sat down with Andrew to break down the architecture: how durable execution keeps long-running workflows alive, how to debounce alerts so you don't spam users, and how serverless workers on Google Cloud Run handle sudden spikes in demand without overprovisioning.
What's in the video
- Durable execution 101: How Temporal allows you to rewind history to the point of failure.
- The Entity Workflow pattern: Why there is one persistent workflow per user subscription and separate monitoring workflows per showing across the country.
- Signals & smart debouncing: How showing workflows send signals to wake up subscription workflows, and how a 60-second in-workflow timer batches multiple theater alerts into a single digest—without consuming active CPU while sleeping.
- Serverless workers on Cloud Run: How running Temporal workers as serverless containers lets compute autoscale directly with task queue depth rather than generic CPU metrics.
-
AI agents for ops: How modern coding agents paired with Terraform and the
gcloudCLI accelerated the deployment and operational dashboard setup.
The point that stuck with me is how durable execution fundamentally changes how you think about long-lived state and retries. Instead of building complex cron jobs, custom retry databases, and alert queues, the workflow state itself is the queue and the timer.
Have you experimented with entity workflows or running workflow workers on serverless infrastructure? How do you handle debouncing and noisy downstream APIs in your own apps?
Top comments (0)