Server Architecture

A single IRC server (ircd) handles thousands of clients with classic TCP server architecture:

Real ircds use epoll/kqueue for thousands of concurrent connections.

State per server:

• All clients (nick → connection).
• All channels (name → set of clients + modes).
• All servers it's linked to.

State synchronization across servers:

• Server-to-server protocol (similar to client but extended).
• New connection: SYNC clients, channels, modes from peer.
• Each command relays to peers.

Linking topology:

• Originally tree: each server has one parent (no loops).
• A→B→C; if B fails, A and C disconnect.
• Spanning tree limits message duplication.

Netsplit:

• Tree splits when a link breaks.
• Each side processes only its visible state.
• Heal: re-link, sync, broadcast user/channel deltas.

Modern alternatives:

• InspIRCd: modular, popular.
• UnrealIRCd: feature-rich.
• Charybdis (powering Libera.Chat): clean codebase.
• Ergo (Go-based, modern, single-binary).

Scaling limitations:

• Single ircd: ~50k-100k concurrent clients (memory + IO).
• Multi-server network: scale horizontally; each server has subset of users.
• Modern Slack/Discord: shard database + many app servers; abandoned tree topology.

Persistence:

• Channels: typically in-memory only. ChanServ persists ACLs.
• Messages: NOT persisted (ephemeral by design).
• Logs: server-side optional logging.
• Bouncers (BNCs): per-user message buffers.

Authentication: SASL via NickServ/services. Or "umode +x" host cloaks.