How a rate Limiter took down GitHub

Rate Limiters are supposed to avoid downtimes, but what if they turn out to be the root cause of a major outage?

A large chunk of GitHub users saw elevated error rates and this happened after deploying their A/B Experimentation service. So, what went wrong? but before that let's understand what is A/B experimentation

What is A/B Experimentation?

It is hard to decide which UI is better and hence before rolling out any critical UI change to all the users, a company tests it through an A/B experiment.

A set of users are chosen at random and a fraction of them are shown the new variation while others are shown the old one. Key vitals and metrics of the features are measured and compared to decide if the variation is indeed an improvement.

If the metrics are positive and significantly better then the new variation is rolled out to 100% of the users. This way companies ensure that the features that are rolled out are genuine improvements in the product.

A/B Testing at GitHub

Every server that needs to participate in any A/B experiment fetches a configuration file that is dynamically generated using, say, Config Generator service.

The configuration allows granular controls for the A/B experiment and holds critical information that shapes experimentation. When any server requests for a config file, the request hits the config service and it, in turn, generates the file and sends it back to the user.

What failed?

Because a lot of requests were made to the Configuration Service, the rate limiting module of the service started throttling and it prevented the configuration file to be generated and sent to the servers.

This affected the users who were part of this experiment and they saw elevated error rates as the frontend did not have the necessary information it required to power the experiment.

Mitigation and Long-term Fix

As quick mitigation, the GitHub team disabled the dependency on the dynamically generated file and it restored the services to normal.

To ensure the outage would not happen due to the same reason, the Config Generator service would generate and cache the configuration files so that when a request comes, the file could be served directly from the cache instead of generating on the fly which was time consuming.

Key Takeaways

• avoid sync dependencies between services and prefer async
• classify the services by severity tiers and run periodic audits of tier-1 services to ensure they are architected well and there are no blindspots

Here's the video of my explaining this in-depth ?? do check it out

Rate limiters are supposed to avoid downtimes, but have you ever heard that a rate limiter caused a downtime? This happened with GitHub, where a big chunk of their users saw elevated error rates.

In this quick incident dissection, let's take a look at a high-level overview of how GitHub does their A/B experiments, how a low-level decision led to this incident for a large chunk of users, and conclude with some key things we all should learn from this outage.

Outline:

• 00:00 Agenda
• 02:32 What happened?
• 02:47 What is A/B Experimentation?
• 05:33 A/B Experimentation at GitHub and what failed
• 11:12 Mitigation and Long-term Fix
• 12:04 Key Takeaways

Check out the free course covering all GitHub outages → https://courses.arpitbhayani.me/github-outage-dissections/

You can also

• Subscribe to the YT Channel Asli Engineering
• Download the notes
• Listen to this on the go on Spotify

Thank you so much for reading ?? If you found this helpful, do spread the word about it on social media; it would mean the world to me.

You can also follow me on your favourite social media LinkedIn, and Twitter.

Yours truly,

Arpit

arpitbhayani.me

Until next time, stay awesome :)

I teach a course on System Design where you'll learn how to intuitively design scalable systems. The course will help you

• become a better engineer
• ace your technical discussions
• get you acquainted with a massive spectrum of topics ranging from Storage Engines, High-throughput systems, to super-clever algorithms behind them.

I have compressed my ~10 years of work experience into this course, and aim to accelerate your engineering growth 100x. To date, the course is trusted by 600+ engineers from 10 different countries and here you can find what they say about the course.

Together, we will build some of the most amazing systems and dissect them to understand the intricate details. You can find the week-by-week curriculum and topics, benefits, testimonials, and other information here https://arpitbhayani.me/masterclass.