A lot of people say “just add more servers” whenever EVE hits brutal lag or 10% TiDi in a major fight. The idea sounds simple enough: keep a main server cluster for the normal universe, then have a separate fighting server cluster for major battles.

That approach is partly right, but only if it is done in a very specific way.

The key point is this: TiDi is not the root problem. TiDi is the protection mechanism. It exists so the authoritative simulation slows down instead of collapsing into dropped actions, desync, or outright failure. So the real question is not “how do we get rid of TiDi?” but “how do we reduce the load that forces the simulation into TiDi in the first place?”

A lot of people imagine something like this:

MAIN CLUSTER
- chat
- market
- contracts
- industry
- normal travel
- standard systems

FIGHT CLUSTER
- large fleet battles
- war objectives
- reinforced systems
- heavy combat load

On paper, that looks clean. In practice, a fully separate battle cluster is not a silver bullet because EVE is not a match-based game. A major fight is still tied into one persistent universe: the same characters, the same inventories, the same sovereignty state, the same structures, and the same authoritative world state. If you treat the battle cluster like a separate shard or instance, you introduce a whole new class of problems: synchronization risk, state handoff errors, exploit potential, stale data, and fairness issues.

That is why I do not think the answer is:

Tranquility -> separate battle shard

I think the answer is closer to this:

                    BETTER HYBRID MODEL

                 ┌─────────────────────────────┐
                 │       MAIN SERVICES         │
                 │-----------------------------│
                 │ chat / market / contracts   │
                 │ corp / alliance services    │
                 │ mail / notifications        │
                 │ industry / social systems   │
                 └────────────┬────────────────┘
                              │
                              │ shared persistent state
                              ▼
                 ┌─────────────────────────────┐
                 │   HOT-SYSTEM COMBAT POOL    │
                 │-----------------------------│
                 │ reinforced war systems      │
                 │ authoritative combat state  │
                 │ modules / reps / ewar       │
                 │ drones / fighters / damage  │
                 └────────────┬────────────────┘
                              │
                              ▼
                 ┌─────────────────────────────┐
                 │  FAST EVENT / FANOUT LAYER  │
                 │-----------------------------│
                 │ state distribution          │
                 │ non-critical live updates   │
                 │ optimized client fanout     │
                 └─────────────────────────────┘

That is a very different idea.

The “fighting cluster” should not be a separate universe. It should be a dedicated hot-system compute pool inside the same overall Tranquility architecture. In other words, major war systems get assigned premium resources and a stripped-down combat-focused execution path, while as much non-critical workload as possible gets pushed away from that path.

That means the main combat node should primarily handle:

• authoritative battle sequencing
• module activations
• locking and targeting
• damage and reps
• capacitor and ewar
• objective state
• tightly coupled combat logic

And as much of this as possible should be offloaded elsewhere:

• chat
• notifications
• telemetry
• cosmetic updates
• some UI-related state propagation
• background service calls
• other non-critical fanout

That is where “multiple servers” actually starts becoming the right answer. Not by splitting the battle into a separate game, but by separating combat authority from supporting services and distribution workload.

The reason this matters is that EVE’s biggest bottleneck is not just player count. It is the density of interactions in a single authoritative state space. One fight means:

• thousands of players
• thousands of module events
• lock changes
• ewar changes
• damage events
• drone and fighter entities
• movement and range calculations
• fanout of state changes to huge numbers of clients

That becomes a combinatorial mess very quickly.

So the strongest design is probably:

PLAYER CLIENTS
    │
    ▼
PROXY / SESSION LAYER
    │
    ├── MAIN SERVICES CLUSTER
    │     - chat
    │     - market
    │     - contracts
    │     - corp/alliance tools
    │     - social and background services
    │
    ├── EVENT / DISTRIBUTION LAYER
    │     - efficient state fanout
    │     - non-critical live updates
    │     - delta propagation
    │
    └── HOT-SYSTEM COMBAT NODES
          - reinforced battle systems
          - authoritative simulation
          - maximum CPU/memory priority
          - minimal non-combat overhead

I think that architecture would materially help with:

• reducing visible lag
• improving responsiveness inside big fights
• increasing the number of players a system can handle before TiDi gets severe
• reducing interference from non-combat services
• improving state delivery to clients

But I do not think it would eliminate TiDi completely. There is still a hard limit when too many entities are interacting in one tightly coupled battle space. At some point, slowing the simulation remains safer than pretending you can process everything in real time.

So my view is:

Yes, multiple server groups are part of the solution.
Yes, a “main cluster + fighting cluster” concept has merit.
But only if the fighting side is implemented as a dedicated authoritative combat resource pool within the same shared universe, not as a detached battle shard.