1. The system with no stable answer

Liu Cixin’s The Three-Body Problem is named after the mathematical problem of predicting three gravitationally bound bodies. There is no general stable solution; the system can look consistent for a while and then surprise you. Distributed storage in orbit has the same quality: you can try to enforce perfect order, but hardware failures and network partitions will eventually test your assumptions.

Entry 226 chose an object store interface. This entry decides how strict the consistency should be.

2. Strong versus eventual consistency

Strong consistency means every read returns the most recent write. This is what application developers usually want, because it lets them ignore timing and ordering.

Eventual consistency means reads can return slightly stale data, but if you wait and stop writing, all copies eventually agree. This is easier to build across unreliable hardware and networks.

The trade-off is between developer convenience and system availability. A strongly consistent system may have to reject reads or writes when a storage cell is unreachable. An eventually consistent system can keep answering, but the answers might be old.

3. Different data, different rules

The desktop does not need one consistency level for everything.

  • Earth observation archive. Mostly write-once, read-many. Eventual consistency is fine. A processed image may take a few seconds to appear in all copies, which is acceptable.
  • Downlink buffer. Needs to know which data has been sent and which has not. Here, losing track is expensive. Strong consistency or at least careful serialization is worth the cost.
  • Customer configuration and commands. These change rarely but matter enormously. Strong consistency is required so the platform does not act on stale instructions.
  • System state and logs. Eventual consistency is acceptable, as long as the ordering is preserved well enough for debugging.

4. The practical choice

The object store layer should support two consistency classes by default: an eventually consistent class for archives and logs, and a strongly consistent class for state and commands. This is not exotic; many terrestrial object stores already do this.

The compute attachment’s applications can choose which class to use. A processing pipeline writes to the archive class. The platform’s own control software writes to the strong class.

5. What this costs

Strong consistency requires more coordination: locks, quorums, or a designated leader. This adds latency and complexity. But for the small, critical datasets that need it, the cost is small compared to the cost of acting on stale data.

What this changes

  • The desktop storage layer should offer two consistency classes, not one universal rule.
  • Earth observation archives use eventual consistency; commands and platform state use strong consistency.
  • This split lets the simple parts stay simple while the critical parts stay safe.
  • The next entry can pick candidate object store software that supports this split.