[Conceptual illustration of space-based computing infrastructure communicating via inter-satellite links. Image generated using an AI image generation tool (OpenAI), for illustrative purposes only.]
Servers in Space
Crazy Idea or Legitimate Architectural Alternative?
I used to love showing my students Figure 8-1 from the 2007 INCOSE SE Handbook v3.1. It was a simple diagram contrasting two completely different ways to solve the same problem: how do you connect a telephone call between two people on opposite sides of the Atlantic? One approach goes up, through a satellite. The other goes down, under the ocean, through a cable. Same stakeholder need. Radically different architectures [1]. I would let that image sit on the screen for a moment and then ask the class which approach was older. Most of them knew the cable predated the satellite — (I mean, duh.) — but almost none of them understood by how much. The first transatlantic telegraph cable dates to 1858, though it took until 1866 to get one that actually stayed working [2]. That gap between “I knew it was older” to “I had no idea it was that old” usually got the room thinking in exactly the right direction about what architectural alternatives are actually for.
Figure taken from International Council on Systems Engineering (INCOSE), Systems Engineering Handbook, Version 3.1, INCOSE-TP-2003-002-03.1, 2007
I bring this up because Elon Musk recently floated the idea of putting servers in space [3], and while that headline generated the usual mix of breathless enthusiasm and eye-rolling skepticism, the systems engineering angle is more interesting than either reaction. Strip away the personality and the press coverage and what you have is a proposal for a fundamentally different system architecture intended to satisfy largely the same stakeholder needs as today’s terrestrial data centers. Which is precisely the kind of comparison the INCOSE SE Handbook has been encouraging practitioners to make since at least Version 3.1.
The underlying principle has not changed much between that 2007 edition and the current Version 5.0. The System Architecture Definition process directs practitioners to develop and evaluate alternative architectural solutions that genuinely differ from each other in how they meet system requirements, address constraints, and account for life-cycle considerations [4]. The key word is “genuinely.” The goal is not to generate a list of options that are all slight variations on the same concept so you can document that you considered alternatives. It is to surface options that challenge the baseline assumptions of the leading concept. The satellite-vs-cable diagram was a good illustration of that principle precisely because no one looking at those two concepts would confuse them for variations of each other.
Terrestrial data centers represent the mature, dominant architectural concept for large-scale computing. Resources are centralized or regionally distributed on Earth, supported by power grids, cooling systems, fiber-optic networks, and physical access for maintenance and upgrades. This architecture carries embedded assumptions that rarely get examined simply because the concept is so familiar: proximity to terrestrial energy infrastructure, feasibility of hands-on maintenance, reliance on conventional cooling. Even within that terrestrial concept there is already a surprising range of variation. Hyperscale providers have deliberately sited facilities in Scandinavia to reduce cooling loads, while others operate in repurposed underground mines to improve thermal stability and physical security [5, 6, 7]. Those within-domain variations are interesting, but they are all still working within the same fundamental set of constraints. They are optimization, not architectural imagination.
Putting servers in orbit is something different. The operating domain changes entirely. Solar energy replaces grid power. Maintenance strategies that assume someone can show up with a wrench get replaced by strategies that assume no one can show up at all, which means autonomy, redundancy, and a very different approach to acceptable failure rates. Scaling becomes tied to launch cadence rather than construction schedules. Regulatory considerations expand from local zoning and environmental compliance into orbital spectrum coordination and space traffic management. Whether these tradeoffs ultimately favor the space-based concept is a separate question from whether the concept is worth examining. The INCOSE Handbook’s point, and the point of that old satellite-vs-cable figure, is that the examination itself is where the value lies. Concepts that seem impractical often expose hidden assumptions in the preferred alternative. And concepts that seem impractical occasionally turn out, after proper analysis, to be quite practical.
The enduring lesson in all of this is not about servers or satellites or transatlantic cables. It is about what happens when you force yourself to compare architectural approaches that are genuinely, structurally different from each other. You expose the assumptions your preferred concept has been quietly depending on. You clarify which stakeholder needs are truly non-negotiable and which ones reflect habit more than requirement. And you end up with a much stronger rationale for whichever architecture you ultimately select, because that rationale has been tested against a real alternative rather than a straw man. So when you are next sitting in a design review and someone floats an idea that sounds impractical or even a little absurd — servers in space, cables on the ocean floor — the systems engineering question worth asking is not “is this realistic?” but rather:
“What does this alternative reveal about the solution we have already convinced ourselves is the obvious answer?”
Optional Reader Resource
A practical worksheet aligned with the INCOSE System Architecture Definition process to help teams compare fundamentally different architectural concepts before converging on a solution.
References
International Council on Systems Engineering (INCOSE). Systems Engineering Handbook, Version 3.1. INCOSE-TP-2003-002-03.1, 2007. Figure 8-1.
“Transatlantic telegraph cable.” Wikipedia. https://en.wikipedia.org/wiki/Transatlantic_telegraph_cable
Driebusch, Corrie, et al. “Why Elon Musk Is Racing to Take SpaceX Public.” The Wall Street Journal, 21 Jan. 2026. https://www.wsj.com/tech/why-elon-musk-is-racing-to-take-spacex-public-38f3de9b
International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Version 5.0. Wiley, 2023. https://www.incose.org/resources-publications/technical-publications/se-handbook/
Google. “Data Centers: Efficiency and Location Strategy.” Google Sustainability, 2019. https://datacenters.google/operating-sustainably/
Meta Platforms, Inc. “Our Global Data Center Infrastructure.” Meta Data Centers, 2020. https://datacenters.atmeta.com/
“Inside ‘The Underground.’“ Iron Mountain, Nov. 2025. https://www.ironmountain.com/data-centers/about/news-and-events/news/2024/december/data-centers-inside-the-underground-iron-mountain-in-butler-county
