How SushiBytes made one of the smoothest Cardano NFT launches.
The Cardano NFT community has experienced all kinds of launches, from the initial web launch of SpaceBudz, the Google Doc launch of CardanoBits, to the very unique Discord launch of PlanetPalz. Whatever possible way there is to launch an NFT, you can be sure that the Cardano community has tried it all. There is no lack of ingenuity in the Cardano community. At SushiBytes, we are fans of the original SpaceBudz launch, and we wanted to replicate that experience and bring back that hassle-free, instant buying process. However, with the bot attacks that plagued recent launch sites, and the sheer number of people rushing to launch sites, is it still even possible?
The SushiBytes minting and delivery system was built on the shoulders of giants, giants like Alessandro of SpaceBudz. If you haven’t already done so, I recommend reading this SpaceBudz article on how they architected their NFT minting and delivery which has become the basis for many Cardano NFT launches. Since the minting and delivery is well written there, I’ll focus on the launch site from here on.
For the launch site, we faced 3 problems:
1. How much traffic will there be and how do we handle that traffic?
2. How can we fend off a bot attack?
3. How can we reduce uncertainty?
For the first problem, we needed a ballpark figure to estimate traffic. I based this ballpark off of the first launch of CryptoKnitties that experienced 500,000 requests in about 30 minutes (figure based off of their Discord #announcement channel soon after their launch). That is about 278 requests per second. That became the minimum target number. Looking at our launch site, on average it can complete requests in 37ms. That means, one instance of our launch site could handle 27 requests per second (1,000ms / 37ms = 27rps). On the day of the launch, we deployed 40 instances of the launch site behind the load balancer, which is 40 instances * 27rps = 1,080 requests per second that we were able to handle. We ended up experiencing 115,000 requests in the first 10 minutes. That’s 192 requests per second, we had plenty of capacity.
For the second problem, we needed to find a solution to stop a bot attack, and ideally to stop the bots before they even land on our site. We found that solution in Cloudflare. Using the Pro version of Cloudflare, we turned on the “Super Bot Fight Mode” feature and we proxied our DNS through Cloudflare. This meant that before requests even make it to our load balancer, Cloudflare has checked that the request is made from a real browser by running a series of tests including a JavaScript test.
Finally, as this was a launch, we did not have data on how users will behave, which presented a lot of uncertainty. We made a deliberate decision to keep the launch site as simple as possible. This is more of a philosophy and style that I carry as a software engineer. The more code written, the more places that the code could break. That’s because software engineers are human: the more we do, the more mistakes we make. Therefore, we coded only the minimum for the launch site, enough to reveal the payment instructions, show users the SushiBytes they received, and that’s it. Some suggested that we should not allow users to open multiple browsers, or to queue users up. We decided not to write code for that, and opted for the absolute minimum code to deliver buyers their SushiBytes.
We are very happy with the launch of SushiBytes and the overall smooth experience that our users received. Our sale is still ongoing at app.sushibyte.io as of this writing and you can follow @Sushi_Bytes on Twitter.
