Servers and Scale

This chapter's thesis: the vanilla server's "one process runs one world" model was refitted by the community, layer by layer, into "many processes orchestrate one game" — a ten-thousand-player network and a singleplayer save share the same kernel code, but they are already two species; vanilla never made interest management (whose information goes to whom, whose world runs for whom) a first-class citizen, and third-party cores filled the vacancy. If some ten-thousand-player server runs smoothly on an unmodified vanilla server, this thesis is wrong.

1The problem

A singleplayer save: one computer, one world, one player, a few dozen entities. A ten-thousand-player network: dozens of machines, hundreds of worlds, tens of thousands of messages a second, hundreds of thousands of entities (spread across processes). Both set out from "the same server program" — one more contrast beyond the three claims at the door of this volume: shared code, but long since not the same species.

Volume I, chapter 5 covered servers from the social angle — server admins as legislators, the Bukkit crisis (see The Server Is the New Game); chapter 10 covered the authority model through the protocol. This chapter trains the lens on the last unopened layer: scale. How was one and the same kernel code refitted, step by step, into shapes that serve a hundred, a thousand, ten thousand players? And what kind of evidence does each layer of patches accumulate for Volume IV's "rewrite exam"?

2A singleplayer save and a mega-server: really the same program?

Formally, yes. The backend machines of a ten-thousand-player network all start out running that official jar (or one of its downstream branches) — the same world-simulation kernel, the same twenty-tick contract, the same block-update logic. This is the dividend of the "unified abstraction" (chapter 10 told that story): behavior agrees everywhere, and every gameplay asset is portable.

In fact, no. The vanilla server's comfort zone is the low hundreds of players: one process, one main thread, one world to a ledger. Its architectural assumption — one process = one world = one simulation — begins to strain at a few hundred players and fails outright at ten thousand: no single machine can run an entire world shared by tens of thousands of players. And so each order of magnitude the architecture grows a new organ: at hundreds of players, parameter tuning and performance plugins suffice; at thousands, multi-world splitting (players distributed across several parallel worlds); at ten thousands, multi-process, multi-machine, plus proxy routing. Scale does not amplify; it deforms — a ten-thousand-player network is already a distributed system, and the vanilla jar's role within it has degenerated from "the whole game" to "the simulation kernel on each node."

Does a street-corner shop and a chain corporation run on the same recipe? Perhaps. They are obviously not the same kind of business. The story of server scale is this metaphor's engineering edition.

3The server genealogy: a river of ever-thicker patches

Lay out the main species along this line of descent (the social history lives in Volume I, chapters 4 and 5; here we read the architectural contributions):

The vanilla server: the baseline. Correct, conservative, a single-threaded main loop, no plugin interface. It is every downstream's "semantic origin" — however much downstream changes, behavior is benchmarked against it (its performance is not).

Bukkit + CraftBukkit: the plugin interface grafted on (Volume I, chapter 4 covered its two-layer interface/implementation split — see Mods as the Second Author). Its architectural contribution was to standardize "the server's programmability" as events and hooks — from then on, third parties could change server behavior lawfully, without each one hand-editing bytecode.

Spigot: a performance-oriented fork of CraftBukkit, which replaced large amounts of vanilla's "correct but slow" implementation with "behavior-compatible but faster" versions and opened finer configuration. Its architectural contribution is a principle made flesh: performance patches can proceed without breaking the plugin interface — that discipline gave the entire downstream ecosystem a stable load-bearing surface.

Paper: downstream of Spigot, taking this road to its extreme — thousands of patches, large amounts of its own configuration, its own bug fixes. At this point Paper is in effect "a re-implementation with vanilla as its compatibility target": players run Paper; behavior is benchmarked to vanilla. Chapter 9's "folk official implementation" here comes true a second time, and this time on the simulation core — the rendering debt could be outsourced; now even the debt of world simulation has found a contractor¹.

Folia: an experimental branch the Paper team introduced in recent years, doing the one thing most forbidden in vanilla architecture — splitting open the single-threaded world main loop: the world is cut into regions that settle in parallel, each region ticking on its own. Chapter 5 established that the 20-TPS single main loop is the foundation of the causality contract; Folia's radicalism lies exactly there: it is betting that "regionalized parallelism will not shatter causality." It remains experimental, and large numbers of plugins are incompatible with it — but its very existence is a milestone: the single-thread assumption, the deepest architectural foundation of all, has been moved by the community's own hands. Volume IV, chapter 5 (Simulation Scheduling) has an exam to sit; Folia is the first folk answer sheet handed in.

4Distance and sharding: the two levers of scale

The engineering essence of large scale is answering two questions: whose world runs for whom (the dispatch of simulation), and whose information goes to whom (the dispatch of synchronization). Vanilla handles both implicitly and coarse-grained: the world within simulation distance runs for the player (chapter 3); information within view distance is sent to the player (chapter 10).

The community forged both levers into explicit tools. On the simulation side: entity caps, chunk priorities, settlement tiered by activity level — making "compute finely near the player, coarsely far away, or not at all" a configurable strategy (Folia's regional parallelism is the limiting form of this line). On the synchronization side: multi-world splitting and proxy routing — proxy servers (the BungeeCord line through the Velocity generation) stand in front of every backend process; players connect to the proxy, and the proxy ferries players "across" to this or that backend world as needed. To the player it is one seamless big game; to the architect it is several independent processes plus a switch. A cross-process teleport must migrate player state (inventory, position, progress) — in distributed systems, the most classic and treacherous problem there is — and server admins work this problem in production, every week.

5The ops stack: another game nobody sees

The full technical stack holding up a ten-thousand-player network goes far beyond "the server program": proxies do routing and load balancing; anticheat (chapter 10's guerrilla war) runs an around-the-clock credibility profile on every player; backups and rollback are the admin's regret medicine — scheduled snapshots, instant rollbacks, the "turn back the clock" after one governance incident or one malicious attack, all of it leaning on chapter 2's save system (Storage and Serialization) put to operational use; monitoring draws TPS, memory, and entity counts into dashboards, so the alarm sounds before the world slows down.

That this stack exists at all is a declaration: operating a large server is an engineering discipline, and server admins are the most underrated group of engineers in the game (chapter 5 of Volume I kept their labor inventory). What they are really playing is a meta-game called "let tens of thousands of people seamlessly fail to notice the existence of these dozens of machines," and the clear condition is that nobody perceives anything amiss. This game has no save points — going live is starting the run.

The meta-game has its disaster script too, and walking it once shows how the ops stack interlocks. Three in the morning, the monitoring alarms: some backend's TPS has fallen to single digits. The duty admin's troubleshooting order is close to a reflex — read the dashboard to locate the process; read entity counts and chunk counts to judge simulation overload against memory trouble; if needed, grab a thread dump to see where the main thread is stuck. The diagnosis: a large-scale chain reaction some player just triggered (chapter 4's graph-computation storm). The options come ordered by severity: clear the involved entities remotely (surgery); roll the world back to a backup from ten minutes ago (amputation); restart the entire backend (defibrillation). Every step weighs the players' loss — a rollback swallows ten minutes of everybody's labor. Disposal done, a notice goes up; most players wake up never knowing of the midnight surgery. In professional operations circles the routine is commonplace — but mark where it happens: on the server of a "game," and the hands performing it usually belong to unpaid enthusiasts. This meta-game is hardcore enough for any server room.

6Large servers: another way to use the engine

Fold this chapter back into the book's big picture. Volume I already established that Minecraft's product boundary was never just the client (mods hold the second author's seat — see Mods as the Second Author); this chapter adds the architectural edition of that claim: large server networks are another way to use the engine — the same kernel, orchestrated into a distributed system, carrying a scale vanilla never imagined. This is not "an extension of vanilla" but a derived product form: the product experience of a ten-thousand-player network (seamless travel between servers, a shared economy, live events) stands farther from the vanilla singleplayer experience than any mod does — and depends on the kernel more than any mod does.

Along this line of descent there is also a numerical relationship worth examining on its own: the larger the code change, the more important the semantic anchor. A fair share of Paper's thousands of patches are "byte-for-byte benchmarking" against vanilla behavior — to confirm an optimization did not alter some corner behavior, the community maintains behavior-comparison test suites. Chapter 8's quasi-connectivity, chapter 4's update order, chapter 7's item components — every piece of "behavior players depend on" became an exam point that every downstream implementation must reproduce. The role of the vanilla code has changed here: it is no longer "the implementation" but the semantic reference implementation of the entire ecosystem — even though it cannot run at scale, its behavior remains the ground truth that every large-scale variant must align to. A hobbyist codebase from 2009 becoming an industry's standard reference implementation is a fate rare even by the standards of software history.

And the vacancy filled again and again along this evolutionary route — interest management is not a first-class citizen — is vanilla architecture's deepest unpaid debt: whose information goes to whom, whose world is computed for whom, which entities are worth settling at all — at ten-thousand scale, these core questions get vanilla's answer of "implicit rules plus hard-coding," and the community dug them out layer by layer into explicit tools (the separation of simulation distance, entity budgets, regional parallelism). When Volume IV, chapter 5 designs "simulation scheduling," it will keep this viewpoint: a rewritten engine that seats interest management in the kernel as a first-class citizen would, in a single stroke, complete fifteen years of manual evolution on behalf of every server admin. Wherever the community has gotten to is the rewrite volume's starting line.

7What this chapter leaves behind

• For players: the big server you frequent is a precision ballet of dozens of machines — the next time it lags, you will know which role to feel for.
• For developers: what you can take away is the deformation theory of scale — every order of magnitude crossed, the architecture grows a new organ (tuning, multi-world, sharding, proxies); do not expect a single-player architecture to "hold up against everything"; and take the first-class citizenship of interest management as an advance indicator. What you cannot take away is the compatibility discipline: Paper's thousands of patches, never breaking the plugin interface for over a decade, were held up by treating "behavior benchmarked to vanilla" as religion — this kind of restraint has no crash course.

注释

1. Wikipedia, "Minecraft server" (the lineage and relations of server software such as Bukkit, Spigot, and Paper; Paper is an optimization-oriented fork in wide use among large servers), Wikipedia, retrieved 2026-09-18: see https://en.wikipedia.org/wiki/Minecraft_server . ↩