Presentation: Capacity Planning for Crypto Mania

Track: Production Readiness: Building Resilient Systems

Location: Pacific LMNO

Duration: 10:35am - 11:25am

Day of week: Wednesday

Level: Intermediate

Persona: Architect, Chaos/Resiliency/SRE, Technical Engineering Manager

Share this on:

What You’ll Learn

  • Learn about how Coinbase had to deal with the Cryptocurrency spikes of 2017.

  • Hear about capacity planning has been changed and affected by the lessons the company learned last year.

  • Hear about the tension between synthetic traffic and playback for load testing, and then understand more about how Coinbase reasons about the choices they make for planning.


Over the course of 2017, Coinbase experienced exponential user and trading volume growth, which in turn led to periods of website instability and downtime. During this period, we saw our systems perform at the very edge of their capacity which inspired important capacity and performance improvements. Since then we have sought new ways to push our systems to their limits so that we can be sure that we are focusing our energy on the right projects. 

Come to hear how Coinbase engineers are applying lessons from these experiences to create new tools and techniques for capacity planning to prepare for future waves of cryptocurrency enthusiasm.


What's the focus of the work that you do today?


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.


The spike that you're talking about is bitcoin basically going from $6,000 to $18,000 in a really short period of time. Is that right?


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.


What does this spike mean in terms a software engineer can relate too? What does a $6,000 to $18,000 price jump mean to your 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.


So now that the load is off, how did the events of 2018 change how you all plan?


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.”


Can you pick one example of something you might discuss that will be in the talk about something somebody may be able to apply?


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.”

Speaker: Jordan Sitkin

Software Engineer @coinbase

Find Jordan Sitkin at

Speaker: Luke Demi

Software Engineer @coinbase

Luke Demi is a Software Engineer on the Reliability Team at Coinbase. In his spare time he enjoys ultralight backpacking and competing against Folsom St Strava segments.

Find Luke Demi at

Similar Talks

Security Researcher, Leader, Advisor @Netflix
Staff Security Engineer @Cruise Automation
Engineering Director @ShapeSecurity & JavaScript Expert
Tech Lead Fairness, Transparency, Explainability & Privacy Efforts @LinkedIn
Senior Researcher in the Quantitative Financial Research Group @Bloomberg
Senior Manager & Heading AI for Growth and Communication Relevance @LinkedIn


Monday, 5 November

Tuesday, 6 November

Wednesday, 7 November

The all-new QCon app!

Available on iOS and Android

The new QCon app helps you make the most of your conference experience. Easily browse and follow the conference schedule, star the talks you want to attend, and keep tabs on your personal itinerary. Download the app now for free on iOS and Android.