In case you missed it, we launched our partnership game with Chipotle last weekend.
Granted, this overlapped the most extended outage that Roblox had seen to date, but it was still a fantastic achievement for our team - specifically, our web team.
Roblox experiences typically live entirely on the platform. Roblox does a great job at providing services that scale without much intervention for everything from databases to server-side scripting. However, when given a dataset of over 100,000 free burrito codes, the setup needs are more complex. We couldn't rely on Roblox in this case, and instead, we had to build our external tool to distribute these codes to hungry Chipotle fans.
Simultaneously while building our game, we developed an in-house distribution system to scale with the demand we anticipated. This system would be accessed using Roblox's HTTPService, where our app that was sitting on Google Cloud would keep track of the request queue for codes, take note of who's who, and then respond with a unique code for each. What sounds simple in premise left us with a lot of challenges to solve:
- How do we ensure code requests always yield a unique result?
- How should we deal with Roblox HTTPService limits?
- How do we deal with batch cycling from day to day?
With a lot of testing and tinkering, we solved it. Using App Engine as our app "frontend" and request queue to communicate to a Cloud SQL instance for the backend ended up working like a charm. Our Roblox game servers also had a local request queue thanks to their newly unveiled MemoryStore - just in case the HTTP limit for a particular instance was reached, players still kept their general position in line.
The result? Many happy players that had Chipotle for dinner thanks to a Roblox game. The future is here.
- Devon