Capacity Planning

GitHub was acquired by Microsoft in October 2018. Within weeks, traffic patterns shifted in ways nobody had modeled. Developers who had been avoiding GitHub because of uncertainty started returning. New Microsoft internal teams migrated to GitHub for source control. Traffic grew faster than any historical trend had predicted, headroom evaporated, and the infrastructure team had to react instead of plan.

The postmortem was clear: annual capacity reviews are not enough. GitHub moved to a quarterly capacity loop with monthly reviews, and they started modeling growth from business events (acquisitions, enterprise deals, free tier expansions) instead of extrapolating from historical RPS alone.

This is the core tension of capacity planning. Spreadsheets are always wrong. They assume the future looks like the past, which is true right up until a product launch, an acquisition, a viral moment, or a marketing campaign changes the shape of traffic overnight. But spreadsheets are also the best tool you have if you combine them with real load tests, business inputs, and enough headroom to absorb forecast error. The goal is not to predict the future perfectly. The goal is to never be caught without enough capacity to serve your users.

Capacity planning is not one meeting or one spreadsheet. It is a continuous pipeline with four stages, and each stage feeds the next.

The pipeline runs quarterly. Between quarters, monthly check-ins compare forecast to reality and adjust if the gap grows beyond 10%. The entire point is to order capacity before you need it, because cloud providers are not infinitely elastic. Large instance types sell out regionally during peak events, quota increase requests take days or weeks, and stateful database expansions cannot happen in minutes.