GitHub’s DGit Improves Reliability, Performance, and Availability

GitHub has been quietly rolling out DGit, short for “distributed Git”, a new distributed storage system built on top of Git with the aim of improving reliability, availability, and performance of using GitHub.

DGit is an application-level protocol that leverages Git’s distributed nature by keeping three copies of every repository on three different, independently chosen servers. This simple architecture has a number of immediate benefits in terms of reliability, availability, and performance, according to GitHub:

the possibility that all three servers where a repository is hosted become unavailable at the same time is highly unlikely, assuming that the three servers are independent on one another;

user requests can be load-balanced across the three servers; since the majority of them are reads, they can be served immediately and do not require any synchronization across the three servers, with a direct, almost 3x performance improvement;

“fate sharing” among repositories is greatly reduced. Fate sharing is the circumstance that leads to performance degradation for one or more repositories due to their sharing the same server with another, highly popular, or too large repository. Indeed, since repositories are replicated on independent servers it is highly unlikely that the same circumstance occurs on all three of them. This makes if possible to serve a request from less overloaded servers.

replica servers need not be close together, thus they can be located in different availability zones and/or data centers. Behind the obvious availability improvement, this also brings better performance for geographically closer users.

DGit allows GitHub to do away with the backup-based scheme that was previously used (and still is while DGit rollout is taking place). For each active file server, that scheme required a dedicated spare server connected by a cross-over cable, to which data were synchronized using DRDB.

when a server fails, the only measure that must be taken is routing all pending requests to a new server and reboot the failed one;

additionally, replacing a faulted server is not that urgent anymore, since there are still two servers working, which are then quickly replicated to a third one;

not using a dedicated spare server means that GitHub may better use every CPU and all memory they have available to serve user requests;

DGit makes it much simpler to manage GitHub infrastructure, e.g., adding new servers, handling repositories becoming very large or popular, etc.

DGit, as mentioned, is built on top of Git itself and does not take advantage of RAID, DRBD, or other replication technologies. Instead it has to implement its own algorithms for serializability, locking, failure detection, and resynchronization. In conversation with InfoQ, GitHub explained that they are using the 3-phase commit protocol to handle distributed transactions and that “DGit has almost eliminated service interruptions from the Git layer caused by single host or whole rack outages”.

As mentioned, GitHub has been gradually rolling out DGit for the last months, starting with their own repos, then moving to a number of high-profile public repositories once they gained confidence in the new system. Finally, during last February, GitHub began moving repositories in bulk. Currently, about 60% of all repositories and 98% of all Gists, accounting for 67% of all GitHub data, are already working in DGit and “import jobs to DGit from the legacy storage architecture are running around the clock”, GitHub stated to InfoQ.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.