October 21 post-incident analysis
The timeline of events was interesting (and much appreciated), but the root cause analysis doesn&#x27;t really go much deeper than &quot;we had a brief network partition, and our systems weren&#x27;t designed to cope with it&quot;, which still leaves a whole lot of question marks.<p>Of course, without detailed knowledge of how GitHub&#x27;s internals work, all we can do is speculate. But just based on what was explained in this blog post, it sounds like they&#x27;re replicating database updates asynchronously, without waiting for the updates to be acknowledged by slaves before the master allows them to commit. Which means the data on slaves is always slightly out-of-date, and becomes more out-of-date when the slaves are partitioned from the master. Which means that promoting a slave to master will <i>by definition</i> lose some committed writes.<p>If &quot;guarding the confidentiality and integrity of user data is GitHub’s highest priority&quot;, then why would they build and deploy an automated failover system whose purpose is to preserve availability at the cost of consistency? And why were they apparently caught off-guard when it operated as designed?<p>(Reading point 1 under &quot;technical initiatives&quot;, it seems that they consider intra-DC failover to be &quot;safe&quot;, and cross-DC failover to be &quot;unsafe&quot;. But the exact same failure mode is present in both cases; the only difference is the length of the time during which in-flight writes can be lost.)