The Good Tech Companies - How Supercell Powers its Massive Social Network with ScyllaDB

Episode Date: December 30, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/how-supercell-powers-its-massive-social-network-with-scylladb. Supercell powers real-time cross-game chat, presence, and notifications for millions using ScyllaDB Cloud, enabling low-latency, scalable events. Check more stories related to gaming at: https://hackernoon.com/c/gaming. You can also check exclusive content about #game-server-scaling, #real-time-gaming-backend, #hierarchical-key-value-store, #low-latency-database, #supercell-id, #event-driven-architecture, #scylladb-cloud, #good-company, and more. This story was written by: @scylladb. Learn more about this writer by checking @scylladb's about page, and for more stories, please visit hackernoon.com. Supercell scaled real-time, cross-game social features for hundreds of millions of players using ScyllaDB Cloud. With just two engineers, they built Supercell ID for account management, chat, presence, and notifications, leveraging hierarchical key-value storage, Change Data Capture, and low-latency writes to handle massive concurrent events efficiently and reliably.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. How Supercell powers its massive social network with Skyladyby by Skyladyby. How a team of just two engineers tackled real-time persisted events for hundreds of millions of players with just two engineers, Supercell took on the daunting task of growing their basic account system into a social platform connecting hundreds of millions of gamers. Account management, friend requests, cross-game promotions, chat, player presence tracking. and team formation. All of this had to work across their five major games. And they wanted it all to be covered by a single solution that was simple enough for a single engineer to maintain, yet powerful

enough to handle massive demand in real time. Supercell server engineer, Edvard Fagerholm, recently shared how their mighty team of two tackled this task. Read on to learn how they transformed a simple account management tool into a comprehensive cross-game social network infrastructure that prioritized both operational simplicity and high performance. Note, if you enjoy hearing about engineering feats like this, join us at Monster Scale Summit, Free Plus Virtual. Engineers from Disney Plus, Hulu, Slack, Canva, Uber, Salesforce, Atlassian, and more will be sharing strategies and case studies.

Background. Who's Supercell. Supercell is the Finland-based company behind the Hid Games heyday, Clash of Clans, Boom Beach, Clash Royale and Brawlstars. Each of these games has generated $1 billion in lifetime revenue. Somehow they managed to achieve this with a super small staff. Until quite recently, all the account management functionality for games servicing hundreds of millions of monthly active users was being built and managed by just two engineers. And that brings us to Supercell ID. The genesis of Supercell ID. Supercell ID was

born as a basic account system, something to help users recover accounts and move them to new devices. It was originally implemented ASA relatively simple HTTP API. Edvard explained, the client could perform HTTP queries to the account API, which mainly returned signed tokens that the client could present to the game server to prove their identity. Some operations, like making friend requests, required the account API to send a notification to another player. For example, do you approve this friend request? For that purpose, there was an event queue for notifications. We would post the event there, and the game back-end would forward the notification to the client using the game socket. Enter two-way communication. After Edvard joined the Supercell ID project in late

2020, he started working on the notification backend, mainly for cross-promotion across their five games. He soon realized that they needed to implement two-way communication themselves, and built it as follows. Clients connected to a fleet of proxy servers, then a routing mechanism pushed events directly to clients, without going through the game. This was sufficient for the immediate goal of handling cross-promotion and friend requests. It was fairly simple and didn't need to support high throughput or low latency. But it got them thinking bigger. They realized they could use two-way communication to significantly increase the scope of the supercell ID system. Edvard explained, basically, it allowed us to implement features that we re-previously part of

the game server. Our goal was to take features that any new games under development might need and package them into our system there by accelerating their development. With that, Supercell ID began transforming into a cross-game social network that supported features like friend graphs, teaming up, chat, and friend state tracking. Evolving Supercell ID into cross-game social network. At this point, the social network side of the back end was still a single-person project, so they designed it with simplicity in mind enter abstraction finding the right abstraction we wanted to have only one simple abstraction that would support all of arrasis and could therefore be designed and implemented by a single engineer explained edvard in other words we wanted to

avoid building a chat system a presence system etc we wanted to build one thing not many finding the right abstraction was key and a hierarchical key value store with change data capture fit the bill perfectly. Here's how they implemented it. The top-level keys in the key value store are topics that can be subscribed to. There's a two-layer map under each top-level key, map, string, map, string, string. Any change to the data under a top-level key is broadcast to all that-key's subscribers. The values in the innermost map are also timestamped. Each data source controls its own timestamps and defines the correct order. The client drops any update with an older timestamp, stamp and what it already has stored.

A typical change in the data would be something like level equals 10 feet change sto, level equals 11. As players play, they trigger all sorts of updates like this, which means a lot of small rights are involved in persisting all the events. Finding the right database they needed a database that would support their technical requirements and be manageable, given their minimalist team. That translated to the following criteria, handles many small rights with low latency, supports a hierarchical data model, manages backups and cluster operations as a service. Skyladybee Cloud

turned out to be a great fit. Skyladyby Cloud is the fully managed version of Skyladyby, a database known for delivering predictable low latency at scale. How it all plays out. For an idea of how this plays out in Supercell games, let's look at two examples. First, consider chat messages. A simple chat message might be represented in their data model as follows. Edvard explained, the top-level key that's subscribed to is the chat room ID. The next level key is a timestamp UID, so we have an ordering of each message and can query chat history. The inner map contains the actual message together with other data attached to it. Next, let's look at Presence, which is used heavily in supercells new and highly anticipated, game Mo. Co. The goal of Presence, according to Edvard, when teaming up

for battle, you want to see in real time the avatar and the current build of your friends, basically the weapons and equipment of your friends, as well as what they're doing. If your friend changes their avatar or build, goes offline or comes online, it should instantly be visible in the teaming up menu. Players state data is encoded into Supercell's hierarchical map as follows. Note that the top level is the player ID, the second level is the type, and the inner map contains the data. Supercell ID doesn't need to understand the data, it just forwards it to the game clients. Game clients don't need to know the friend graph since the routing is handled by Supercell ID. Deeper into the system architecture. Let's close with a tour of the system architecture, as provided by Edvard.

The back end is split into APIs, proxies, and event routing, storage servers. Topics live on the event routing servers and are sharded across them. A client connects to a proxy, which handles the client's topic subscription. The proxy routes these subscriptions to the appropriate event routing server. endpoints E, G, for chat and presence, send their data to the event routing servers, and all events are persisted in Skyladybee Cloud. Each topic has a primary and backup shard. If the primary goes down, the primary shard maintains the memory sequence numbers for each

message to detect lost messages. The secondary will forward messages without sequence numbers. If the primary is down, the primary coming up will trigger a refresh of state on the client, as well as resetting the sequence numbers. The API for the routing layers is a simple post-event RPC containing a batch of topic, type, key, value tuples. The job of each API is just to rewrite their data into the above tuple representation.

Every event is written in Skylidibi before broadcasting to subscribers. Our APIs are synchronous in the sense thought if an API call gives a successful response, the message was persisted in Siladibi. Sending the same event multiple times does no harm, since applying the update on the client is an item potent operation, with the exception of possibly multiple sequence numbers mapping to the same message. When connecting, the proxy will figure out all your friends and subscribe toothair topics, same for chat groups you belong to. We also subscribe

to topics for the connecting client. These are used for sending notifications to the client, like friend requests and cross-promotions. A router reboot triggers a resubscription to topics from the proxy. We use protocol buffers to save on bandwidth cost. All load balancing is at the TCP level to guarantee that requests over the same HTTP 2 connection or handled be the same TCP socket on the proxy. This lets us cache certain information in memory on the initial listen, so we don't need to refetch on other requests. We have enough concurrent clients that we don't need to separately load balance individual HTTP, two requests. As traffic is evenly distributed anyway, Andre quests are about equally expensive to handle across different

users. We use C-Persistent sockets between proxies and routers. This way, we can easily sentence of thousands of subscriptions per second to a single router without an issue. But it's not game over. If you want to watch the complete tech talk, just press play below. And if you want to read more about Skyladyby's role in the gaming world, you might also want to read, Epic Games, How Epic Games uses Skyladyby as a binary cache in front of NVMe and S3 to accelerate global distribution of large game assets used by Unreal Cloud DDC. Tencent Games How Tencent Games Built Service Architecture based on CQRS and event sourcing patterns with

Pulsar and Skyladyby. Discord How Discord uses Skyladyby to power their massive growth, moving from a niche gaming platform to one of the world's largest communication platforms. Thank you for listening to this hackernabee. Hackernoon story, read by artificial intelligence. Visit hackernoon.com to read, write, learn and publish.