Why Elah exists

Why Elah exists

Large Minecraft communities often want more players, more activity, and larger worlds. A single powerful machine can go far, especially with modern server software, but it is still one machine with finite CPU, memory, storage, and network capacity.

Elah explores a different question:

Can one logical world use several machines without making players install a special client or turning world safety into a gamble?

The motivation

The goal is not to spread work across machines merely because it looks impressive. The goal is to make growth more practical while preserving the parts players care about:

• one familiar Java client connection;
• one connected world;
• consistent inventories and positions;
• no duplicated authoritative areas;
• understandable recovery when something fails.

Safety before scale

Distributed systems can create failures that one server never has. A delayed network message can look like a dead machine. A restarted worker can hold old information. Two machines can accidentally believe they both own the same area.

Elah's central rule is simple: uncertain ownership must not create a second writer. Temporary unavailability is better than silent corruption, duplicated items, or lost world state.

This is why the roadmap begins with small laboratories, read-only inspection, one worker, and fixed boundaries. Dynamic scaling comes much later.

Why the project moves in stages

Each stage should prove one narrow claim before the next stage depends on it:

1. the repository and tests are repeatable;
2. different programming languages agree on control messages;
3. world inspection is read-only and trustworthy;
4. one connected worker behaves normally;
5. two workers can own fixed areas without overlap;
6. a player can cross a boundary without duplication or loss.

That order makes failures easier to understand and reduces the chance of building a large system on an unproven assumption.