GitHub 负载均衡系统最初是为了处理 Git 的数十亿日常连接而开发的。
GitHub 将发布开源版的 GitHub 负载均衡软件（GLB），这是内部开发的负载均衡系统。
开发 GLB 的初衷是满足 GitHub 的这一要求：每天处理数十亿的 HTTP 连接、Git 连接和 SSH 连接。而如今，这家公司将通过开源来发布 GLB 的组件，到时会透露设计方面的细节。
GitHub 的高级基础设施工程师乔·威廉斯（Joe Williams）和 GitHub 的基础设施工程经理西奥·朱利恩（Theo Julienne）在一篇共同撰写的公告中说：“在过去，我们的负载均衡层一向是比较复杂的组件之一。传统上，我们纵向扩展这个部分，运行一小批运行 haproxy 的超大型机器，并使用非常特定的硬件配置，以便实现专门的 10G 链路故障切换机制。”
但是这个负载均衡平台遇到瓶颈后，该公司开始着手开发自己的解决方案。这个新平台要满足某些目标，包括横向扩展、高可用性、支持连接清空（connection draining），并且能应对分布式拒绝服务（DDoS）攻击。“为了实现这些目标，我们需要重新考虑 IP 地址与主机之间的关系、我们的负载均衡层包括的各个层，以及连接是如何路由、控制和终结的。”
GitHub 在设计负载均衡平台时，为流量引导器（traffic director）这层竭力改进常见模式。该公司最后选用了一种支持多个查询的聚集哈希（rendezvous hashing）。每个代理主机存储起来，并被分配一个状态，然后处理连接清空。固定大小的转发表生成后，使用聚集哈希的排序组件，每一行都填满了代理服务器的地址。表和代理主机状态被发送到引导器服务器，并保持同步。
TCP 数据包一发送到引导器，源端 IP 就经过哈希处理，生成指向转发表的一致性索引。数据包在注定发送到代理服务器内部 IP 的另一个 IP 数据包里面加以封装，并通过网络发送出去。代理服务器收到经过封装的数据包后，拆开数据包，在本地处理原始数据包。出站数据包使用服务器直接返回（Direct Server Return）模式，那样发送到客户端的数据包就直接发送到客户端、绕过引导器这一层。
这两位工程师说：“我们着手设计一种新的引导器层，它具有无状态性，让引导器和代理节点都可以从容地退出轮转，在任何可能的情况下，对用户没有干扰。一些用户生活在互联网连接不尽如人意的国家，所以合理大小的代码库的长时间运行副本不会在合理时间的计划维护期间出现故障，对我们来说很重要。”