Part 1/2
Space data centers and lunar infrastructure sound compelling, until you examine the engineering details.
The concept is attractive.
The problem begins when it scales.
Every additional satellite increases orbital complexity, collision probability, conjunction risk, station-keeping demand, radiofrequency coordination, end-of-life disposal pressure, and the total cross-sectional area exposed to the micrometeoroid and orbital debris environment.
The argument that “the impact of one object is minimal” breaks down the moment you stop talking about one object and start talking about hundreds, thousands, or entire constellations.
That is how isolated technical risks become systemic risks.
This is where Kessler Syndrome enters.
In 1978, Donald Kessler and Burton Cour-Palais described a scenario in which the density of objects in Earth orbit becomes high enough that collisions generate fragments, those fragments cause more collisions, and the process begins feeding itself.
Not as a single accident.
As a cascading fragmentation event.
The orbital environment is already congested. ESA’s current figures estimate tens of thousands of tracked objects in Earth orbit, more than 16,200 tonnes of orbital mass, and model-based populations of roughly 54,000 objects larger than 10 cm, 1.2 million objects between 1 and 10 cm, and 140 million fragments between 1 mm and 1 cm.
That matters because even small debris can be destructive at orbital velocity.
A paint-chip-sized fragment in low Earth orbit is not “dust” in the ordinary sense. It is a hypervelocity projectile.
Adding data infrastructure to that environment does not neutralize the risk.
It adds mass, traffic, heat rejection systems, power systems, propulsion requirements, failure modes, and strategic value to an already fragile orbital regime.
The Moon is not the magic solution many imagine, either.
On Earth, closed-loop or near-zero-water cooling is still not the global baseline for hyperscale data centers. We are still managing trade-offs between water use, energy use, cooling efficiency, thermal rejection, maintenance access, spare parts, supply chains, and operational resilience in places where we have atmosphere, gravity, roads, technicians, and immediate access to resources.
So no… there is no solid engineering reason to assume this becomes easier 384,000 kilometers away.
A lunar data center would not only need computing hardware.
It would need power generation, energy storage, radiation shielding, thermal management, dust mitigation, redundant communications, robotic maintenance, fault-tolerant systems, and some realistic strategy for repair when something breaks.
Then there is lunar dust.
It is not soil.
It is abrasive, electrostatically active, and it sticks to almost everything. Apollo already showed how lunar regolith damages seals, wears down equipment, clogs mechanisms, degrades thermal surfaces, coats instruments, and complicates maintenance.
For lunar infrastructure, that means every radiator, hatch, seal, panel, filter, joint, cable, rover, robot, bearing, actuator, connector, and moving component becomes part of the engineering problem.
Half a century after Apollo, lunar dust remains one of the most stubborn technical nightmares in serious Moon-base planning.
And even if in-situ resource utilization becomes viable, “using local resources” is not a magic phrase. ISRU still requires extraction, processing, power, equipment, maintenance, redundancy, and logistics. You do not escape infrastructure by moving to the Moon.
You multiply the infrastructure needed to keep the infrastructure alive.
But the deepest problem is not technical.
It is strategic.
Any critical infrastructure beyond Earth stops being purely technological infrastructure.
It becomes power infrastructure.
And once that infrastructure exists, so does the incentive to attack it, disable it, capture it, blind it, jam it, ransom it, or turn it into leverage.