How we built GitLab Geo
Sep 14, 2018Gabriel Mazetto
Summary
This post details the initial architectural decisions and implementation phases for GitLab Geo. It covers the MVP phase with decisions on using native database replication, API calls for disk changes, Git for repository replication, and a primary-node-only authentication model using OAuth. It also discusses not replicating Redis data or user attachments initially. The first-generation synchronization mechanism leveraged webhooks for change notifications, improving upon the MVP's custom API.
More from the High Availability trail
- Consolidate your GitLab stack with Gitaly on Kubernetes
- GitLab backs 99.9% availability SLA with service credits
- Downtime happens, but GitLab Incident Management can help
- How we are closing the gap on replicating *everything* in GitLab Geo
- How we tested a feature that affected (almost) all parts of GitLab