Presentation: Capacity Planning for Crypto Mania

Jordan: We’re on the Reliability Team at Coinbase. It was formed in response to the crazy spike of scaling challenges around 2017 with Cryptocurrency. The work is focused on traditional SRE topics of monitoring and instrumentation. We act as consultants for other mostly feature-focused teams. For example, we embed in teams to make sure that they're putting in place best practices of shipping scalable versions of the features they are implementing, or we make sure long-term plans are in place for things like capacity planning, alerting, and PagerDuty. Capacity planning is a big part of our day-to-day work now so we think it’s a great fit for the Production Readiness track.

Jordan: Yeah. That's the story of cryptocurrency so far. It is these crazy (almost overnight) run ups in price that put lots of stress on everyone’s systems.

Luke: It's important to make clear that the prices are very important. They correlate really closely to the amount of traffic we see. However, they're not really relevant in terms of our scaling challenges. The price being $4,000 versus $20,000 doesn't change the way we operate at the ground level (although it may mean that there's a lot more traffic due to increased interest).

Luke: In terms of how a developer would understand the load, we grew traffic by 60x between our normal load at the beginning of 2017 and our peak traffic in December. We went from regularly around 30,000 requests per minute on average to peaks in December of 1.5 million requests per minute. A lot of little things we didn't expect to have happen to us when we joined this company happened. Things like, we were the number one app in the App Store for a week. That's a big part of the talk. It’s the idea it could happen to you.

Luke: And to add a little bit to what Jordan said, this new team formed over 2018, but in 2017, we did all these actions that this team is doing now. We just did them under the gun. We built capacity planning frameworks in an afternoon. Then we built them again next weekend, and the weekend after. So we learned a lot of lessons which have been super valuable. We’ve had the chance now to step back and plan things a bit differently. We’re going to share some of these lessons.

Luke: We started with a question. If we were to get hit with the same amount of traffic that we were able to withstand in December, how confident are we that we would be able to withstand it? That's why we had to double down on capacity planning. We had to get this going correctly if we were going to be able to reliably answer that question. We've double down on capacity planning.

Luke: There are big questions here. For example, do you need to actually simulate 1.5 million requests per minute for your tests? Are there other approaches? How perfectly do you need to simulate the load in terms of user traffic? There is a major tension between simulation testing and replay testing. How are we approaching them? What are the pros and cons of both? These are challenges that we've had to approach this year.

Luke: We feel like we're starting to get a feel for how this actually looks in a real day-to-day environment.

Jordan: And on that note, I think when a lot of people talk about capacity planning, it’s sometimes with this air of it being a somewhat one-time, slightly academic exercise. One of the themes that I want to make sure we get into our talk is here's how you practice capacity planning on an ongoing basis in a real organization that's operating on a similar scale to where we were at the end of 2017.

Jordan: We don't necessarily have a single expert in load testing and capacity planning, but it's something that is important to acknowledge and get done. I have a little comment here in my notes that says “I want this talk to be the one that I wish I had seen exactly one year ago, and I want you to address me as a somewhat experienced engineer in a generalist sense facing something similar.”

Jordan: I think one thing we're going to talk specifically about is load testing our database. The database was one of our biggest challenges. That specific bottleneck is something I spent time building specific tooling on. I'd like to give some actual hands-on details about how that tool works, what it does, and then give some takeaways that are general learnings about how you load test a database in isolation.

Jordan: We’ll also touch on this tension between synthetic traffic and playback. Specifically addressing how you honor all the things that you need to achieve while still walking that line between the two.

Luke: On simulation testing, I'm hoping people can walk away thinking, “Oh, that's not that bad, to be able to do those types of things.”

Luke: I hope the message we're giving people is that “These broad concepts can be applied to my environment, and it's approachable.”