Destined To Fail

Considering running a GraphQL API gateway? Have you ever thought about the number of things that could go wrong, when users consume your the data exposed? What happens when a service you depend upon is gone? What’s the maximum amount of data you could live without?

TV 2 Denmark is the largest, Danish television broadcaster and has the most popular, subscription-based streaming service in Denmark. We use GraphQL as a an API gateway for our different platforms, connecting our customers with all our microservices through a singular API. During spring of 2018, in preparations for streaming the Soccer World Cup, we discovered our weaknesses and dependencies on other internal, and external services, and why handling failure was imperative in order to survive the massive herds wanting to stream the World Cup.

In this talk I’ll walk you through some hard-earned lessons on dealing with failing dependencies in GraphQL, failing gracefully, not overexposing your internal weaknesses and why network optimization is suddenly necessary in the world of asynchronous API calls.

I’ve been working as a software engineer for the last 15+ years, having worked on some of the largest services in Denmark. I spent the major part of the last year running point on the reliability and scalability challenges within the largest, Danish streaming service, TV 2 PLAY. The efforts have been focused on chaos engineering, optimizing internal communication between services and hunting for milliseconds in our responses.