How Supercell Handles Real-Time Persisted Events with ScyllaDB

Supercell runs five games that have each earned over $1B in their lifetime, together pulling in hundreds of millions of monthly players. The account and social backbone behind all of them, Supercell ID, was built and operated by a team of two engineers. That headcount shaped every technical decision that follows.

This one layer handles account recovery, friend graphs, chat, presence, notifications, and cross-game promotion. A larger team might build a separate service for each. Two people cannot maintain six systems, so they set out to build one.

It did not start ambitious. Supercell ID began as a plain HTTP API for account recovery and device migration: a client queries the account API and gets back signed tokens the game server trusts. Cross-player actions like friend requests rode a one-way event queue, where the account API posted an event and the game backend relayed it to the client over the game's existing socket.

When Edvard Fagerholm joined in late 2020, the driver was cross-game promotion: the team needed to push notifications to clients directly. That meant a fleet of proxy servers clients connect to, with routing that delivers events straight to the device and skips the game server.

Then came the realization: that same two-way layer could absorb friend graphs, chat, presence, and teaming up, all the things that used to live inside each game server. Build it once at the ID layer and every future game inherits it for free.

With effectively one engineer on the design, the bias was blunt: one abstraction that covers every use, not a purpose-built service per feature. The one thing they built is a hierarchical key-value store with broadcast. Top-level keys are topics clients subscribe to, and under each topic sits a two-layer nested map, map(string, map(string, string)).

Any change to data under a top-level key is broadcast to every subscriber of that key. Ordering rides on timestamps: every innermost value is timestamped, each data source controls its own ordering, and clients drop any update older than what they already hold.

That last rule matters. Conflict handling lives on the client, so the server never has to reason about staleness. It just stores and forwards.

The payoff is that things which look nothing alike ride the exact same structure. A chat message and a player's live battle status are stored identically.

For chat, the topic is the room ID, the second-level key is a timestamp-UUID that gives both ordering and queryable history, and the inner map holds the message, metadata, and reactions. For presence, heavily used in the new game mo.co so teammates see each other's weapon, level, and status live, the topic is the player ID and the inner map holds the state itself.

Supercell ID never parses any of it. It does not know what a weapon is or what the friend graph means. It forwards opaque tuples and owns the routing; the game client, in turn, never has to know the friend graph at all.

The database had to satisfy three things at once. It needed to handle many small writes with low latency, because the workload is a constant stream of tiny state deltas like level 10 → level 11. It needed a hierarchical model that matched the nested-map topic layout. And it needed to manage backups and cluster operations as a service, since two people cannot also be a full-time database ops team.

They landed on ScyllaDB Cloud, the fully managed version, for its predictable low latency at scale and for taking backups and cluster ops off the team's plate. Choosing managed means giving up some control in exchange for not having to run a database, a trade a two-person team happily makes.

Three tiers do the work. APIs are thin: they rewrite incoming data into a canonical (topic, type, key, value) tuple. Proxies are what clients connect to, managing each client's subscriptions. Event routing servers hold the topics, sharded across the fleet, and persist every event to ScyllaDB.

The ordering is deliberate: every event is written to ScyllaDB before it is broadcast. The APIs are synchronous, so a success response means the data is already durable. That costs a little latency and buys a hard guarantee that an acknowledged write will survive.

Each topic has a primary and a backup shard. The primary keeps in-memory sequence numbers per message so it can spot a dropped one. The backup stays passive and forwards messages without sequence numbers, so it does no loss detection while it is not in charge.

If the primary goes down and comes back, it triggers a client state refresh and resets sequence numbers, which reconciles any gaps rather than trying to replay seamlessly. Router reboots trigger automatic resubscription from the proxy layer, and on connect the proxy resolves a client's friends, chat groups, and personal topics in one shot.

Two networking choices keep the fleet cheap to run. Protocol Buffers are the wire format, trimming bandwidth cost. And load balancing happens at the TCP level, not per HTTP/2 request, so every request on a connection lands on the same proxy socket. That lets the proxy cache session info in memory on connect and never refetch it per request.

Coarse balancing works because with huge concurrent client counts traffic spreads out evenly and each user's requests cost about the same, so finer per-request control would add complexity for little gain. Persistent sockets between proxies and routers then let the team push tens of thousands of subscriptions per second to a single router, the one concrete throughput figure they shared.