Sharding

General definition

Sharding is a scale-out technique. Instead of one database holding every row, the data is divided by a shard key (a user ID, a tenant ID, a hash of a message ID) and each shard owns the rows for its range or hash bucket. Reads and writes are routed to the shard that owns the key, so total throughput and storage grow roughly with the number of shards. It differs from replication, which copies the same data to several servers for availability and read scaling, and from vertical partitioning, which splits columns rather than rows.

• Shard key choice is the critical decision: it must spread load evenly (avoid hot shards) and keep the queries you run most inside one shard
• Cross-shard queries and transactions are slower and more complex, so the schema is designed around the key
• Rebalancing moves data between shards as the cluster grows; good systems do it online
• Each shard is usually itself a replica set, so sharding and high availability are combined rather than traded off

MongoDB has sharding built in: a sharded cluster consists of shards (each a replica set), config servers that hold the metadata, and mongos routers that direct queries. Collections are sharded on a chosen key using ranged or hashed distribution, and the balancer migrates chunks between shards in the background. Relational databases shard too, either natively (Citus for PostgreSQL, Vitess for MySQL) or at the application layer.

Chat systems shard along natural boundaries. A room or conversation is the unit that must be consistent (message order, membership), so routing all traffic for a room to one node keeps ordering simple; tenants or apps are a coarser key that also matches isolation requirements. The chat server layer, the message archive and the presence system can each be partitioned on the key that suits them, which is how large messaging platforms handle millions of concurrent connections.

In the Ethora ecosystem

Ethora’s backend is ejabberd for XMPP, a Node.js API layer and MongoDB, all of which are designed for horizontal scaling. Every customer project is an App, an isolated container with its own users, chats and data, so the App is a natural partition key on the managed multi-tenant cluster, and rooms are the unit of ordering underneath it. A dedicated deployment serves one organisation, so its data layer can be sized and sharded for that customer’s volume alone.

Capacity questions are answered with numbers rather than promises: self-hosted and dedicated installs ship with load-testing tools and Grafana and Prometheus monitoring, so a team can measure message throughput, connection counts and database load before growing the cluster. The self-hosted chat server page covers the AWS topology.