GitHub Engineering

GitHub's post-CSP journey

Last year we shared some details on GitHub’s CSP journey. A journey was a good way to describe it, as our usage of CSP significantly changed from our initial release nearly four years ago to where we ended up last year. It wasn’t until then that we felt our policy was relatively stable and, while we were not foolish enough to call it “done,” we found the policy was refined enough to focus on protections beyond what CSP offered.

Moving persistent data out of Redis

Historically, we have used Redis in two ways at GitHub:

Orchestrator at GitHub

GitHub uses MySQL to store its metadata: Issues, Pull Requests, comments, organizations, notifications and so forth. While git repository data does not need MySQL to exist and persist, GitHub’s service does. Authentication, API, and the website itself all require the availability of our MySQL fleet.

How we made diff pages three times faster

We serve a lot of diffs here at GitHub. Because it is computationally expensive to generate and display a diff, we’ve traditionally had to apply some very conservative limits on what gets loaded. We knew we could do better, and we set out to do so.

GLB part 2: HAProxy zero-downtime, zero-delay reloads with multibinder

Recently we introduced GLB, the GitHub Load Balancer that powers GitHub.com. The GLB proxy tier, which handles TCP connection and TLS termination is powered by HAProxy, a reliable and high performance TCP and HTTP proxy daemon. As part of the design of GLB, we set out to solve a few of the common issues found when using HAProxy at scale.

Older posts