Hey there! My name is Michal 0xDEADB33F Ptaszek, and I’m a software architect at Riot. Today I would like to talk about communication. But not the kind of communication you’re probably thinking of. I want to talk about the other, more exciting kind of communication: LoL players communicating with chat servers during a tense game; authentication servers communicating with the LoL client on login; microservices that route state changes between clients in the middle of the night - you know, that kind of communication.
At a high level, communication between services can be split into two groups: synchronous requests, where the sender is blocked until it receives a response, and asynchronous eventing, where messages are fired to the receiver without waiting for a reaction. I want to talk about the latter through the lens of the Riot Messaging Service, a service we built to support scenarios where backend services must inform clients about certain events - such as state changes - in an asynchronous way. The Riot Messaging Service is specifically designed to handle service to client messaging, which comes with its own challenges, requirements, and assumptions.
In this article, I’ll start with a discussion about state changes and the importance of stateful services. Then I’ll move on to the architecture of the Riot Messaging Service that enables linear scalability and high fault tolerance. Last but not least, I’ll focus on a slice of our journey from drawing board to production servers that can support 10 million player connections on a single box. Let’s dive in!
Full post here:
