Design a Gaming Guild Chat

Problem statement

Design a text chat platform for gaming guilds and clans. Members chat in guild channels, officers post announcements and manage roles, the system integrates with in-game events such as boss spawns and guild wars, urgent updates reach offline members through push, and the platform supports emotes, mentions, and pinned messages. Guilds may span multiple game realms, and every realm hosts thousands of guilds.

This is not a clone of a workplace messenger. Three properties make it distinctive. First, the audience is a bounded, stable membership set: a guild rarely exceeds one thousand members and usually sits between thirty and one hundred fifty, which changes the fan-out calculus versus broadcast channels with millions of readers. Second, chat is coupled to game state: a boss-spawn event must land in the right channel as a system message within seconds, rendered in each member's local time, and it must never appear twice. Third, roles and permissions are product-critical: an officer announcement must not be spoofable by a regular member, and demotions must take effect quickly across every cache.

Why the problem is a hard systems problem

A naive design - write a row, notify everyone - collapses under the real numbers. If 3 million players are online at peak and guild chat carries roughly 20,000 messages per second, each message must be ordered within its channel, persisted durably, fanned out to the subset of members currently connected, delivered to absent members when they reconnect, and translated into push notifications for the offline members who were mentioned. Presence - knowing who is online, in which realm, and on which gateway node - is the substrate that makes fan-out efficient, and it is itself a high-write workload of around 100,000 heartbeats per second.

The platform must also survive the failures that multiplayer games live with constantly: gateway nodes die mid-session, realm clusters partition, push providers throttle, and moderation classifiers go down. Each of these needs an explicit degraded mode, because a guild coordinating a raid cannot simply lose its command channel.

Public operating baseline versus design assumptions

Public evidence shows the category operates at extreme scale. Discord's engineering blog describes a message store that migrated from Cassandra to ScyllaDB after the table grew past 175 trillion messages, and a Rust-based Read States service handling around 5 million operations per second. Slack's engineering team publicly moved its largest workspaces - some with hundreds of thousands of members - onto Vitess-sharded MySQL. Twitch has described scaling event chats where hundreds of thousands of participants post concurrently. Riot Games built League of Legends social and chat services to serve tens of millions of concurrent players across regional clusters, and CCP's EVE Online demonstrated single-shard chat loads in the tens of thousands of simultaneous participants. These are cited public figures used as context.

For capacity planning, this answer explicitly assumes a fictional mature MMO platform: 40 million monthly active players, 8 million daily active players, 3 million peak concurrent connections, 200 realm clusters of 15,000 guilds each (3 million guilds), average guild size 60 members, and a peak message rate of 20,000 messages per second with a 3x event multiplier. Unless a number is tied to a named company, it is a stated design assumption.

The four architectural planes

1. Realtime plane: WebSocket gateways, connection registry, per-channel fan-out, presence, and delivery acknowledgement.
2. Message plane: channel ordering, persistence, history paging, read states, pins, and search.
3. Guild plane: rosters, roles, permissions, announcements, and game-event ingestion.
4. Trust plane: inline and asynchronous moderation, reports, enforcement, appeals, and audit.

A strong answer keeps these planes separable. The realtime plane may degrade to reconnect-and-backfill without losing messages; the trust plane may queue without blocking delivery; and the guild plane may cache rosters aggressively as long as permission changes propagate with bounded staleness.