Building a viral Imax ticketing app that never crashes

When 150,000 tickets for The Odyssey in 70mm IMAX went on sale, they sold out almost immediately. The sudden demand posed a problem as cancellations occurred and good seats became available at odd hours. Andrew Baker from Temporal created a service called IMAXXING to monitor all 70mm IMAX showings in the US and notify subscribers when great seats became available. The service quickly gained over 9,000 users.

In an interview, Andrew explained the architecture behind this viral IMAX ticketing app. He discussed how durable execution enables long-running workflows to remain active, even after failures occur. Temporal, the technology used, allows users to rewind history to the point of failure. This is achieved through the entity workflow pattern, where each user subscription has one persistent workflow and separate monitoring workflows for each showing across the country.

To avoid spamming users with alerts, Andrew implemented signals and smart debouncing. When a showing workflow is triggered, it sends a signal to wake up the corresponding subscription workflows. This ensures that multiple theater alerts are batched into a single digest, without consuming active CPU while the workflow is sleeping.

For scalability, Andrew utilized serverless workers on Google Cloud Run. By running Temporal workers as serverless containers, the compute automatically scales directly with the task queue depth, rather than relying on generic CPU metrics. This approach allows the system to handle sudden spikes in demand without overprovisioning resources.

Another key aspect Andrew covered was the use of AI agents for operations. By leveraging modern coding agents paired with Terraform and the gcloud CLI, the deployment and operational dashboard setup was expedited. This approach simplified the management of the IMAXXING service.

The most significant takeaway for Andrew was how durable execution fundamentally changes the way you think about long-lived state and retries. Instead of building complex cron jobs, custom retry databases, and alert queues, the workflow state itself serves as the queue and timer. This simplifies the architecture and makes it easier to manage long-running processes.

The interview concluded with a question from the reporter about whether Andrew had experimented with entity workflows or running workflow workers on serverless infrastructure. He also asked about how to handle debouncing and interactions with noisy downstream APIs in similar applications.