Sharding a GraphQL Gateway for Blast Radius Reduction

Session description

At Airbnb, our GraphQL gateway is a multi-tenant serverless platform hosting 500+ tenants and 1.5M+ lines of application code. Like many large GraphQL systems, it operated as a "shared fate" architecture. To mitigate this risk, we embarked on a multi-year journey to implement traffic sharding at different levels of sophistication. We started with shuffle sharding to reduce the blast radius of any single bad operation. We then added targeted sharding to separate online from asynchronous traffic, to rapidly quarantine misbehaving operations, and to improve the signal-to-noise ratio for our automated canary analysis. Most recently, to mitigate the risk posed by tenants that are used by lots of operations (and thus could bring down lots of shards), we have been working on tenant-aware sharding that minimizes the blast radius of such tenants. We will cover how we architected our sharding solution and how it improved our operational abilities. You will gain a clear understanding of how our implementation tradeoffs have fared over time, key production insights gathered since rollout, and strategies to evolve a GraphQL gateway towards greater isolation without fragmenting the API surface.