Rate limits and reachability when everyone trades at once

Graduate · enrolled learners

This lesson opens with Coinbase outages during volatility, 2020 to 2021.

What happened

During sharp crypto moves, including the crash of May 2021 and various rallies, Coinbase repeatedly slowed, degraded, or went down entirely, so users could not log in, buy, or sell during exactly the volatility they wanted to trade. The cause was not a hack; it was load, a surge of traffic and API requests far above normal, overwhelming finite capacity, so the exchange throttled or failed under the weight of everyone trying to trade at once. An exchange API is not an unlimited pipe: it has rate limits that cap how many requests a client may make, and finite capacity that binds hardest at the moment demand peaks, which is precisely a volatile market. Automated systems that assumed constant, unlimited access found themselves rate-limited, disconnected, or unable to get data, not because of a bug in their own code but because the shared API they depended on could not serve everyone at once. The traders were not locked out by a fault but by the crowd, all hitting the same finite resource in the same minute.

The decision point

An exchange API is a finite, shared resource with rate limits and limited capacity, and both bind hardest under load, so a system that assumes constant, unlimited access will be throttled, disconnected, or starved of data at exactly the moment a volatile market makes everyone hit the API at once. The Coinbase outages are the case: repeatedly, during sharp moves, the exchange slowed or failed under a surge of traffic, and systems assuming unlimited access could not log in, trade, or get data during the volatility they most wanted to trade. This is a subtler venue failure than a full outage: the venue is not necessarily gone, but it is rate-limiting your requests, dropping your websocket, or answering slowly, so the system's access is degraded rather than absent. The engineering point is that access to a venue is a resource that must be managed, not a constant to be assumed: a system must respect rate limits, back off when throttled, reconnect gracefully when a websocket drops, and behave safely when data or acknowledgments are delayed. A system that fires requests as fast as it can, assumes its connection is always live, and treats every request as instantly served is built for a calm market and will fail in a busy one, because the API's limits are real and its capacity is shared with every other participant reacting to the same move. So the discipline is to design order and data flows that degrade safely under throttling and disconnection, to treat rate limits and reconnection as first-class parts of the system rather than afterthoughts, and to remember that the busiest market, the one a strategy most wants to trade, is exactly when the shared API is least able to serve it.

Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.

It is free. We do not sell the list and there is nothing to buy at the end of it.