The GitHub outage of October 21st got its postmortem this week, and it’s an instant classic of the genre, the kind I’ll assign to juniors like homework: a routine maintenance event caused a 43-second network partition between GitHub’s East and West coast datacenters. Forty-three seconds. The failover automation, doing exactly its job, promoted a West Coast MySQL primary while the East Coast primary held seconds of writes that had never replicated. Split-brain: two databases, each believing itself the truth. And here’s the decision that makes it teaching material: GitHub chose consistency over uptime, running degraded for 24+ hours to reconcile data rather than serve wrong answers fast. The postmortem says so, explicitly, trade-off by trade-off. That’s the maturity frontier: not preventing all failure (43 seconds of network weather defeated a world-class team) but choosing your failure mode in advance and documenting the choice like an adult (rehearsed audacity, ops edition). Our own failover’s partition behavior is now a scheduled game-day. I checked. Nobody knew the answer. That’s the finding.
F1 postscript: Lewis Hamilton secured his fifth world championship in Mexico, matching Fangio, a wire-to-wire season coronation (Mercedes’ contingent has transcended insufferable into a kind of serene title nirvana). And IBM announced it’s buying Red Hat for $34 billion, Big Blue betting a third of its market cap that open-source enterprise infrastructure is the future it missed twice already. The 2018 acquisition thesis (terrain, not products) closes the year at maximum volume: code hosts, professional graphs, and now the Linux layer itself.
TIL: orchestrator partition behavior is a configuration expressing a philosophy. Availability-vs-consistency isn’t chosen by your database, it’s chosen by whoever set the failover timeout, probably years ago, probably without a meeting. Find that config. Have the meeting.