F1 Arcade chose NATS so every lap of every race of every customer session is powered by a robust, scalable messaging and data persistence fabric
F1 Arcade adopted NATS to unify their event streaming and messaging processes across venues, replacing a patchwork of systems like MQTT and Redis that lacked reliability and observability at higher loads.
They needed a robust, low-latency, high-availability solution to power real-time racing data, ensuring races always synced correctly—even when venues intermittently lost internet connectivity. NATS JetStream gave them at-least-once delivery, disaster recovery, and the ability to replicate race data for operational visibility and replay.
By centralizing on NATS, F1 Arcade can rapidly scale its venues around the globe with confidence, guaranteeing a consistent experience at every simulator for every customer.
“Instead of relying on a bunch of different systems, we have a one unified and observable and, reliable transport mechanism for all of our communication. So if a message drops, we can replay it.
If a venue loses connection, we don't lose data. It's really positive, and we hope that this is kind of what the future of f one arcade is all about. It's about tons of data, high connectivity, real time experience where every lap of every race and every session is powered by a robust scalable system that can kind of expand with us as we grow, across continents”
— Jamie Allen, Lead Engineer, F1 Arcade on NATS
Go Deeper
Full Transcript
Jamie Allen:
Hi, everyone. I am Jamie Allen. I am one of the lead engineers at F1 Arcade, and I'm just gonna talk to you about how f one arcade uses NATS edge to deliver a fast-paced and high availability and reliable service to our customers. So you probably know very well what Formula One is. F1 Arcade is a state-of-the-art Formula One racing simulator experience coupled with food and drink where people go with their friends or their colleagues to get a taste of the the F1 experience.
And, yeah, we're just getting started. So if you imagine walking into one of our venues, there's the sound of F1 engines in the air. There are around a hundred simulators normally, all running head to head or team racing sessions, streaming real time data to our on-site servers, connected to our central hub. So delivering a taste of the Formula 1 experience. So that's what we're building this point, and I'm just gonna talk to you a bit about how NATS plays a crucial role in making that happen.
So first off, just a little bit about f one arcade itself. So we're backed by Formula One. We opened our first venue in London in in 2022, so quite recently, followed by Birmingham. And in April 2024, we launched our first US site in Boston Seaport. And then after that, we successfully rolled out our f one arcade in Washington Washington DC in autumn twenty twenty four, and have many more venues to come.
So we received a hundred and 30,000,000 in funding in 2024, and because of that, we have some ambitious plans. This year in 2025, we'll be opening up venues in Philadelphia, Denver, Las Vegas, Dubai. And in 2026, we will have plans to open up around 20 venues globally. So you can start to see the technical challenge here. Scaling from four to 30 vent 20 or 30 venues isn't just about that initial setup and logistics.
It's about making sure every venue operates consistently in terms of speed, reliability, and real time data flow. So, yeah, there's there's plenty going on. Just to show what a typical venue looks like. So each venue consists of probably between 50 to a 20 simulators. We have, like, a live updating dashboard in the venue, which venue staff can log in to to manage bookings, see the state of racing sessions.
And then the sims themselves consist of, obviously, the actual seat that you sit in with pedals, steering wheel, but also two PCs, one in front of you for the customer to run the game, and another one above which we call the spectator. And this one gives you other bits of information. So both of those PCs are constantly connected to our central server which is is running our tech stack. So on top of that, you can see here we've got what is called react and lights out. So these are games which kind of test your test your reflexes and your reaction speeds.
And on top of that, we have a bunch of normal hospitality stuff. So tills, a bar, restaurants, a reception, things like that. So, yeah, I just wanted to talk a bit about, I suppose, the previous stack. Before this whole architecture was built with MQTT and Redis and a ball queuing system to ensure message delivery. This all worked fine in certain ways, but there was a lot of, hand rolled logic around queuing.
We had a particular issue in our DC rollout work, which had more simulators than any of the other venues where Redis, despite being adequately provisioned, would go down when running our load testing suite, and we were generally lacking observability of messaging throughout that system, which is a set of microservices talking to each other.
So although it was technically working, there were enough issues knocking around that there was appetite internally to explore different solutions and technologies for for the longer term. And I guess that coupled with, a future vision that included a large increase in the amount of venues that we're supporting plus the possible franchising of venues, plus to support the need for cases such as, you know, intermittent Internet or pop ups, different concepts that we have internally, but, needing a high degree of of service. So, I can sure you can tell where this is all going. So, yeah, after deliberating a bunch of options at the end of last year, we decided on NATS as a communication mechanism for our stack.
So slide here just just a really like high level shows, one of our venues with NATS, as a leaf node, communicating with some of our services, via we actually have a custom NestJS NATS transport, which, we've used to give us type safety in our subjects. So in terms of the features on premises, like NATS JetStreams, obviously, gives you the ability to deliver at least at least once messaging, which means we can always ensure we can provide a stable experience, in racing sessions. And the ability to replicate and observe jet streams using things like mirror streams allows us to add on observability without impacting that core, core messaging of the overall application. So and then on top of that, things like disaster recovery, that's really attractive to us again in the pursuit of maintaining a really consistent experience regardless of what's going on at the venue. So with our old setup, we had situations where sometimes the race data data had gone missing due to missed messages, and a race would finish, but the results might not sync.
So, obviously, that frustrates customers, not great for business. So, we that's what's pushed us towards some of the features that NATS offers. So, yeah, we've we've actually successfully rolled this out to our existing four venues very recently. So we're just in the process of plugging in, some of those benefits. We have got plans to connect mirror streams to our existing stream setup, to allow us observability of that, and also plans to connect our venues, which are essentially leaf nodes to a centralized cluster, with Synadia.
So, yeah, that's gone pretty well. I thought it'd be quite nice to highlight some of the challenges as well because, obviously, people considering, rolling this out in their own companies, you probably wanna know what the hard things are, not the not the good things. So definitely had to do a big migration over to NATS. We changed a bunch of WebSockets, HTTP calls, and MQTT communication to use NATS during the build. So there's no getting around the fact that, you know, nailing down subject names, and things like that is something you you you're just gonna have to work through.
And there's definitely a level of complexity with some of the concepts that NATS brings. So, like, streams, consumers, acknowledgments, all these concepts which you do get familiar with, that's obviously a learning curve for for for a team to take on. And then in terms of performance, yeah, NATS takes a bit of juice as well. Like, the minute we've got, on any of our leaf nodes in a venue, we've got three replica servers. Currently, the streams are split across them, but we'll be moving that to, replicating the streams on each one to allow complete, failover to failure to happen to one of those servers.
So, yeah, that takes a a a bit of beef. I think the minimum requirement is something like two to four CPUs and eight gig of RAM for each one. So just just consideration. So, yeah, I guess just to wrap up, we now have instead of relying on a bunch of different systems, we have a kind of one unified, hopefully observable and, reliable transport mechanism for all of our communication. So if a message drops, we can replay it.
If a venue loses connection, we don't lose data. It's really positive, and we hope that this is kind of what the future of F1 Arcade is all about. It's about tons of data, high connectivity, real time experience where every lap of every race and every session is powered by a robust scalable system that can kind of expand with us as we grow, across continents. So, yeah, we're really excited about what's to come, and thanks for listening.
