When we set out to create a live demo for the Temporal Keynote, we wanted something fun, memorable, and a little chaotic. Enter: Snakes.
Yes, snakes. Specifically, the kind that slither around in a multiplayer game where chaos is not just possible but inevitable. What better way to showcase Temporal’s ability to handle unpredictability than with a snake game running on distributed systems?
The Setup: Multiplayer Snakes Meet Distributed Systems
The Snakes demo wasn’t just an arcade nostalgia trip. It was a live, multiplayer game powered by Temporal, with players controlling their snakes in real time. Every move, collision and apple consumed — Temporal orchestrated it all.
The entire game was powered by Workflows: the game itself, each round, and even each snake operated as independent Workflows.
Our Ingredients
For the demo UI, we wrote a Svelte application and used the awesome Socket.io websocket framework to communicate with the Temporal backend. This gave us the low latency we needed to make the game responsive.
The game Workers (processes executing workflows) ran on a mix of Temporal Cloud and tablets stationed at the front of the stage.
Powered entirely by Temporal, the game managed:
- Every player’s snake as independent workflows.
- Game rounds as separate workflows.
- Moves, collisions, and apple consumption — all orchestrated flawlessly.
Then, we got the game started.
Round One: Smooth Sailing
Angie invited three audience members up on stage to play the game and Steve gave them a quick run down on how to play. For the first round, we kept things simple. Players got to take their time, get a feel for the game, and enjoy devouring apples without any disruption. It was smooth sailing, and the audience cheered as snakes slithered and apples disappeared from the board.
But then, it was time to make things interesting.
Round Two: Introducing Chaos
In the second round, we added some chaos. Every apple eaten would restart a Temporal Worker powering the snakes. The stakes were raised, and the game’s stability was put to the test. Temporal had to recover from these induced outages while ensuring the game continued to run smoothly.
At first, the delays were barely noticeable. Temporal recovered quickly after each Worker restart, and the game barely skipped a beat. But it wasn’t long before the players, quickly improving at controlling their snakes, managed to eat apples faster than they were coming back.
For a brief moment, the game froze—an inevitable consequence of overwhelming the system, all of the Workers were down. But as soon as the first restart completed, Temporal picked up exactly where it had left off. The snakes resumed their slithering, and new apples appeared as the audience cheered.
Round Three: More Chaos
Not content with eating an apple to restart a Worker, I decided that I’d go for something more dramatic: unexpected node failure! After a few apple-eating outages and recoveries, I (sneakily “disguised” in my Temporal hoodie) crept across the front of the stage, pulling the network cables out of the tablets on stage that were running the Workers!
Faced again with the loss of all its Workers at once, the snakes froze. The team on stage quickly realized what had happened, and Drew came to the rescue, plugging everything back in. Within seconds, the snakes were back on the move, carrying on from where they left off.
These disruptions mimic real-world scenarios like server crashes or sudden hardware failures, showcasing how Temporal’s resilience translates to handling unexpected outages in production environments.
Why It Worked
Temporal’s resilience lies in its Durable Execution model. By persisting every step of the Workflows, it ensures that even in the face of chaos, nothing is truly lost. Whether it’s a snake’s position on the board or a critical business process, Temporal makes recovery seamless. You won't need to write code to save state or recover from failures, you get it all for free.
Writing the game was a lot of fun, it’s liberating not having to worry about the normal drudgery of writing a reliable application, and instead focusing on the interesting parts. Less pondering what happens if something crashes in the middle of a round, and more time spent preventing snakes from teleporting across the board or spontaneously splitting in half. I spent longer making sure the snake’s eyes were facing in the right direction than I did writing any error handling code, and yet as we’ve seen, the game wasn’t phased by anything we threw at it.
You can find the code here if you’d like to have a look around. The Temporal code is in the game directory, and the UI code is in the snakes directory. And, if you want to watch the demo as it played out on the stage, you can watch it on YouTube.
What did we learn?
What did we learn from writing a game, and then crashing it in front of a live audience?
1. Temporal is reliable: We knew this already, but Temporal is bullet proof. There was not a single Temporal failure during any rehearsals or the live demo.
2. Socket.io does the job: Coupling Socket.io (or more specifically websockets) with Temporal worked very well. It made it easy to integrate a low latency UI with a reliable Temporal backend.
3. Tablets are flaky: If we were to do this again, we would not use tablets, they were a liability 🫠 While tablets initially seemed like a convenient choice due to their portability and all-in-one design, their limitations became evident once we started rehearsals. The tablets would sometimes turn themselves off, had poor performance due to the virtualization required to run Linux for the Workers and refused to keep a browser window full-screen if the page reloaded. In retrospect, Raspberry PIs with a small screen attached would have saved us a lot of stress!
4. Go performance shines: To handle the Worker restarting mechanism, we ran the snake Workers inside Activities (very meta!). When the Worker was killed because a player ate an apple, the Activity would be retried, bringing the Worker back up. Using the Typescript SDK on the tablets didn’t work very reliably. We ended up having to rewrite the snake Workers in the Go SDK to get the performance we needed. While not something we’d worry about in production use cases on standard nodes, Go worked out better resource wise on our poor underpowered tablets.
5. Activities + unusual observability requirements = magic: While it’s not an everyday requirement, having an Activity that polled the history of the snake Workflows to show which Worker they were on in the UI worked very well. We can imagine this being used for unusual observability requirements, for example auditing a subset of Workflows.
These lessons aren’t just about snake games. They’re a reminder that Temporal excels in demanding scenarios and its flexibility and range of SDKs allows you to choose the right tool for the job!
What’s next?
The Snakes demo wasn’t just a fun highlight of the keynote — it was a testament to Temporal’s ability to thrive under pressure. Whether you’re orchestrating games, workflows, or entire systems, Temporal ensures you’re always ready to bounce back. We can’t wait to see what you build with it. (Just maybe leave the snakes for us, okay?)
See the full demo from Replay ‘24, join us in London for Replay ‘25, and create something fun just like we did with a free trial of Temporal Cloud and $1,000 in free credits.