Interplanetary Distributed Computing System

Межпланетная распределенная система ломает привычные assumptions интернета: высокая задержка, редкие окна связи и partition by default, а не как исключение.

Кейс помогает спроектировать автономные узлы, store-and-forward messaging, deterministic reconciliation и планирование вокруг contact windows и дефицитных ресурсов.

В интервью и architecture review он полезен тем, что заставляет явно пересмотреть все скрытые допущения о сети, времени и координации.

Delay Tolerance

Архитектура должна принимать большие задержки и асинхронную доставку по умолчанию.

Autonomous Nodes

Узлы обязаны выполнять локальные действия при потере центральной связности.

Eventual Sync

Нужны чёткие правила reconciliation и конфликт-резолюции после восстановления каналов.

Resource Constraints

Дизайн учитывает ограниченные compute/energy/network бюджеты edge-среды.

Interplanetary Distributed Computing System - экстремальный кейс для проектирования систем в условиях минутных/часовых задержек, периодических окон связи и длительного offline. На собеседовании он проверяет, умеете ли вы строить автономные контуры, а не только привычный RPC-first backend.

Источник

Hacking the System Design Interview

Глава 15: Design Interplanetary Distributed Computing System с фокусом на delay-tolerant подходы.

Читать обзор

Где этот паттерн встречается

Remote robotics: автономные миссии с редкими uplink/downlink окнами.
Defence/critical edge: сегменты сети с длительными partition.
Offshore/industrial fleets: локальное выполнение задач при потере связи с центром.
Disaster-response systems: fallback режимы в разрушенной инфраструктуре связи.

Документалка

Local First (short summary)

Показывает, почему offline-first и локальная автономность критичны для систем с нестабильной или редкой связью.

Читать обзор

Функциональные требования

Core Command API

POST /commands - сформировать command bundle
GET /commands/:id/status - статус доставки/исполнения
POST /sync/windows/:id - передать delta в окно связи
POST /reconcile - merge конфликтующих обновлений

Mission/Operations функции

Локальное планирование и выполнение задач при полном offline
Store-and-forward доставка с deduplication и retry budget
Приоритеты команд: emergency stop, safety override, routine tasks
Аудит цепочки решений: кто, когда и на основе какого state принял действие

Нефункциональные требования

Требование	Целевое значение	Обоснование
Inter-segment latency	Минуты -> часы	Физические ограничения канала связи
Offline autonomy	24-72 часа+	Сегмент должен выполнять миссию без центра
Delivery guarantee	At-least-once + dedup	Потеря критичных команд недопустима
State convergence	Eventual (по окнам sync)	Согласование состояния после delayed доставки
Observability coverage	Полная трассировка решений	Разбор инцидентов спустя часы/дни после событий

High-Level Architecture

Теория

Distributed Message Queue

Store-and-forward, retry, ordering и delivery semantics в асинхронных контурах.

Читать обзор

High-Level Architecture

command bundles -> autonomous edge execution -> sync window reconciliation

Схема разделяет контуры: отправка команд, автономное выполнение и окно синхронизации.

Earth control plane

Mission Control

global operations

Policy Engine

priority + TTL

Relay Network

store-and-forward

Planetary edge plane

Orbital Gateway

window ingress

Edge Cluster

isolated domain

Local Planner

task sequencing

Execution Workers

idempotent runs

Local Event Log

append-only

Sync + reconcile plane

Result Bundler

delta packaging

Sync Uplink

window transfer

Conflict Resolver

merge rules

Archive Store

canonical timeline

Mission Control

global operations

Policy Engine

priority + TTL

Relay Network

store-and-forward

Orbital Gateway

window ingress

Edge Cluster

isolated domain

Local Planner

task sequencing

Execution Workers

idempotent runs

Local Event Log

append-only

Result Bundler

delta packaging

Sync Uplink

window transfer

Conflict Resolver

merge rules

Archive Store

canonical timeline

Архитектура выделяет dispatch, autonomous execution и sync/reconcile контуры, чтобы система оставалась управляемой при длительных partition и редких окнах связи.

Write/Read Paths

Как command bundles записываются и как state/результаты читаются и синхронизируются при больших задержках.

Write path: центр формирует command bundle, отправляет его через delay-tolerant relay и edge фиксирует команды в локальном журнале.

Command Bundle

Слой 1

mission control

Центр собирает batch команд с приоритетом, TTL и правилами безопасности.

Policy Gate

Слой 2

validate + sign

Policy engine валидирует и подписывает bundle перед передачей.

Relay Network

Слой 3

store-and-forward

Команды доставляются через delay-tolerant relay с retry и dedup.

Edge Queue

Слой 4

local ingest

Orbital/edge gateway принимает bundle и кладёт его в локальную очередь.

Local Event Log

Слой 5

durable append

Команда фиксируется в durable логе для автономного исполнения и replay.

Write path checkpoints

•Команды должны иметь idempotency key, priority lane и TTL.
•Store-and-forward обязателен: доставка может занимать минуты или часы.
•Локальный append-only log нужен для безопасного replay после сбоев.

Консистентность и отказоустойчивость

Глубже

Clock Synchronization

Логические часы, event ordering и управление конфликтами при асинхронной репликации.

Читать обзор

Conflict resolution model

При delayed bi-directional обновлениях merge должен быть формализован заранее:

dominant_update = max_by(priority, logical_time)
if same_priority: merge_by_domain_rules()
ack_state = applied | queued | rejected

Priority lanes - safety-команды всегда выше routine-операций
Idempotent apply - повторная доставка не ломает state
Deterministic merge - одинаковый результат на всех сегментах

Resilience loops

Bundle replay: повтор отправки в следующее окно связи.
Checkpointing: фиксация прогресса задач для recovery после reboot.
Local fallbacks: edge-правила безопасности при потере центра.
Post-sync audit: сверка timeline и инцидентный разбор расхождений.

Глубже

Лэсли Лампорт и распределённые системы

Комментарий: relation happens-before опирается на идею причинности из специальной теории относительности — событие может повлиять на другое только если между ними может пройти сигнал.

Читать обзор

Риски и типовые ошибки

RPC mindset: попытка проектировать межпланетный контур как обычный синхронный API.
No offline-first: отсутствие автономного режима блокирует выполнение миссии.
Weak conflict policy: неформализованный merge рождает непредсказуемый state.
Blind retries: без dedup/idempotency повторные доставки портят данные.
Poor observability: без trace chain невозможно расследовать delayed инциденты.

Что важно проговорить на интервью

Какие операции разрешены только online, а какие гарантированно работают offline.
Как устроены delivery semantics и почему выбран именно такой компромисс.
Как формализован merge-конфликтов между центром и edge-доменом.
Какие SLO мониторятся: sync lag, replay backlog, reject rate, safety override events.

Связанные главы

Distributed Message Queue - Store-and-forward, retry и delivery semantics для каналов связи с высокой задержкой.
Clock Synchronization - Логические часы, порядок событий и контроль конфликтов при больших сетевых лагах.
Consensus Protocols - Границы применения консенсуса и выбор между strict-согласованностью и eventual-моделью.
Local First (short summary) - Offline-first подход и автономность edge-сегмента при длительных окнах недоступности канала.
Лэсли Лампорт и распределённые системы - Happens-before и причинность как основа детерминированного reconcile между сегментами.
Hacking the System Design Interview - Оригинальный кейс и структура собеседовательного обсуждения trade-offs для этой системы.