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 bundleGET /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Схема разделяет контуры: отправка команд, автономное выполнение и окно синхронизации.
Архитектура выделяет dispatch, autonomous execution и sync/reconcile контуры, чтобы система оставалась управляемой при длительных partition и редких окнах связи.
Write/Read Paths
Write/Read Paths
Как command bundles записываются и как state/результаты читаются и синхронизируются при больших задержках.
Write path: центр формирует command bundle, отправляет его через delay-tolerant relay и edge фиксирует команды в локальном журнале.
Command Bundle
mission control
Центр собирает batch команд с приоритетом, TTL и правилами безопасности.
Policy Gate
validate + sign
Policy engine валидирует и подписывает bundle перед передачей.
Relay Network
store-and-forward
Команды доставляются через delay-tolerant relay с retry и dedup.
Edge Queue
local ingest
Orbital/edge gateway принимает bundle и кладёт его в локальную очередь.
Local Event Log
durable append
Команда фиксируется в durable логе для автономного исполнения и replay.
Command Bundle
mission control
Центр собирает batch команд с приоритетом, TTL и правилами безопасности.
Policy Gate
validate + sign
Policy engine валидирует и подписывает bundle перед передачей.
Relay Network
store-and-forward
Команды доставляются через delay-tolerant relay с retry и dedup.
Edge Queue
local ingest
Orbital/edge gateway принимает bundle и кладёт его в локальную очередь.
Local Event Log
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.