{
  "blyg": "0.3",
  "id": "71dpxq9q4xmn10hafzqqw4hyv6",
  "kind": "fragment",
  "origin": "https://www.msweet.net/notes/",
  "page": "938-slate-kites",
  "author": {
    "name": "Matthew McDowell-Sweet",
    "url": "https://www.msweet.net/"
  },
  "created": "2026-08-27T06:38:34Z",
  "updated": "2026-08-27T06:38:34Z",
  "version": 1,
  "content_md": "“Correct when degraded; fast when healthy” is a really neat design principle. Plus, Git and S3 are modern wonders.\n\n> What about consensus? Elections? Which server is the primary for a given repository? It also doesn't matter! There's no state and no consensus here. Any server can be the primary. All updates to the write-ahead log are synchronized with an atomic compare-and-swap (CAS) operation on S3, so it's always safe for any instance of a repository to receive a push. Again, just like with routing, letting an arbitrary server act as the primary isn't the most efficient thing (it leads to CAS retries, which can delay pushes), so in practice we always choose the same server as the primary, the first one in the ranked list from rendezvous hashing. But in the corner cases — when there's a deploy, a failover, a network blip — we just don't care exactly which server is the primary. The system is designed to always be correct when degraded, and always fast when healthy.\n\n[Git at any scale · Cursor ↗](https://cursor.com/blog/git-at-any-scale)",
  "content_html": "<p>“Correct when degraded; fast when healthy” is a really neat design principle. Plus, Git and S3 are modern wonders.</p>\n<blockquote><p>What about consensus? Elections? Which server is the primary for a given repository? It also doesn't matter! There's no state and no consensus here. Any server can be the primary. All updates to the write-ahead log are synchronized with an atomic compare-and-swap (CAS) operation on S3, so it's always safe for any instance of a repository to receive a push. Again, just like with routing, letting an arbitrary server act as the primary isn't the most efficient thing (it leads to CAS retries, which can delay pushes), so in practice we always choose the same server as the primary, the first one in the ranked list from rendezvous hashing. But in the corner cases — when there's a deploy, a failover, a network blip — we just don't care exactly which server is the primary. The system is designed to always be correct when degraded, and always fast when healthy.</p></blockquote>\n<p class=\"source\"><a href=\"https://cursor.com/blog/git-at-any-scale\">Git at any scale · Cursor ↗</a></p>",
  "content_hash": "sha256:40b70d00dd5cba941bec019b54abfe4f00797291828bc98a3a8f2f07459c7a4f",
  "media": [],
  "changelog": [
    {
      "version": 1,
      "at": "2026-08-27T06:38:34Z",
      "note": null
    }
  ]
}