Scaling Room Server for Large Communities

Resource Usage at Scale

Understanding what actually consumes resources on your room server helps you plan upgrades before problems occur rather than after. Three key metrics to watch:

• Memory per connected client: each active TCP/serial connection holds buffers and state. Expect approximately 2–5 MB per connected client depending on activity level and message queue depth.
• Message database growth: roughly 1 MB per 1,000 stored messages, plus index overhead. A community with 50 active users generating 500 messages/day accumulates ~15 MB/month — manageable, but multiplies quickly with multiple rooms and long retention.
• CPU for federation: each federated peer requires periodic sync traffic. A server federating with 5 peers at moderate message rates adds noticeable CPU load on a single-core device.

Signs You've Outgrown a Pi Zero 2W

The Pi Zero 2W (quad-core 1 GHz, 512 MB RAM) is an excellent starter platform, but watch for these warning signs:

• OOM kills: journalctl -k | grep -i "killed process" — if the kernel is killing the room server due to memory pressure, you need more RAM.
• Sustained CPU load > 80%: check with top or htop. Sustained high CPU causes message processing delays and federation lag.
• Client connection timeouts: clients reporting frequent disconnects under load.
• SD card write wear: the Zero 2W's SD card is a bottleneck; high database write rates accelerate wear failure.

As a rule of thumb, a Pi Zero 2W comfortably handles 20–30 simultaneous clients with a single room and no federation. Beyond that, plan an upgrade.

Migration from Pi Zero 2W to Pi 4

Option A: In-place upgrade (swap the SD card image to a Pi 4):

1. Create a full backup as described in the backup guide.
2. Flash a fresh Raspberry Pi OS Lite 64-bit image to a new SD card.
3. Install the room server software on the new card.
4. Restore config and data from backup.
5. Swap the SD card into the Pi 4 and boot.

Option B: Fresh install with config migration (cleaner, lower risk):

1. Set up the Pi 4 as a new server with a new hostname.
2. Copy only the config file and channel keys (not the binary database).
3. Update DNS / federation peer lists to point to the new server.
4. Run both servers in parallel for 24 hours before decommissioning the Zero.

The Pi 4 (4 GB RAM model) can comfortably handle 150+ simultaneous clients and multiple federated peers.

Horizontal Scaling: Two or More Federated Room Servers

When a single server can't handle load — either due to geographic distribution of users or raw client count — split into two or more federated servers. Federation allows servers to exchange messages between rooms, so users on different servers can still communicate.

Architectural considerations:

• Geographic split: assign users to the server nearest to their mesh gateway. Reduces latency and inter-server traffic.
• Topic split: dedicate one server to general chat rooms and another to high-traffic emergency or coordination channels.
• Load balancer: for internet-connected deployments, place an NGINX or HAProxy load balancer in front of multiple room servers that share a synchronized database (requires careful configuration to avoid message duplication).

Before scaling horizontally, ensure your federation configuration is stable and well-tested. Federation bugs (duplicate messages, sync loops) become harder to diagnose with more peers. Monitor federation queue depth on each server to detect bottlenecks.