System Design Space
Граф знанийНастройки

Обновлено: 23 июня 2026 г. в 02:47

Межпланетная распределённая вычислительная система

средний

Классическая задача: автономные узлы, редкие окна связи, передача с промежуточным сохранением и согласование состояния при экстремальных задержках.

Межпланетная распределённая система ломает почти все привычные допущения о сети: задержка измеряется минутами и часами, окна связи редки, а разрыв канала считается нормальным режимом работы, а не исключением.

Кейс помогает спроектировать локальную автономность, передачу с промежуточным сохранением, детерминированное согласование состояния и планирование вокруг редких окон связи и жёстких ресурсных ограничений.

В интервью и архитектурных обсуждениях он полезен тем, что заставляет пересмотреть скрытые допущения о времени, координации и управлении системой в среде, где подтверждение приходит слишком поздно.

Окна связи

Канал доступен редко и ненадолго, поэтому отправку команд, подтверждения и выгрузку результатов нужно проектировать вокруг этих окон, а не поверх них.

Локальная автономность

Удалённый сегмент должен безопасно принимать решения без центра, иначе любая потеря связи превращается в остановку миссии.

Детерминированное согласование

После восстановления связи обе стороны должны одинаково объединять изменения, иначе расхождения будут накапливаться после каждого обмена.

Приоритет безопасности

Аварийная остановка, защитные команды и ручные сценарии вмешательства обязаны иметь явный приоритет над обычными задачами.

Межпланетная распределённая вычислительная система заставляет проектировать сервис так, будто постоянной связи не существует. Задержка измеряется минутами и часами, связь появляется лишь в отдельные , а сеть с большими задержками , а не аварией. Ускорять удалённые вызовы тут бессмысленно. Нужен : удалённый сегмент обязан безопасно вести миссию даже тогда, когда подтверждение от центра придёт слишком поздно, чтобы на что-то повлиять.

Источник

Hacking the System Design Interview

Глава 15: Design Interplanetary Distributed Computing System с акцентом на редкие окна связи, автономность и безопасное согласование состояния.

Читать обзор

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

  • Космические и робототехнические миссии: локальное выполнение задач между редкими сеансами связи.
  • Военные и критические полевые сегменты: длительная изоляция узла и риск потери канала в любой момент.
  • Удалённые морские и промышленные объекты: выполнение операций при нестабильной связи с центром.
  • Системы реагирования на катастрофы: безопасная работа в разрушенной инфраструктуре, где сеть восстанавливается рывками.

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

Local First (short summary)

Хорошо показывает, почему локальная автономность и работа без постоянного подключения критичны в системах с редкой связью.

Читать обзор

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

API командного контура

  • POST /commands - сформировать пакет команд для удалённого сегмента
  • GET /commands/:id/status - получить статус доставки и исполнения
  • POST /sync/windows/:id - передать накопленные изменения в конкретное окно связи
  • POST /reconcile - согласовать конфликтующие обновления после восстановления канала

Функции миссии и эксплуатации

  • Локальное планирование и выполнение задач при полном отсутствии связи с центром
  • с и ограничением на число повторов
  • Явные приоритеты команд: аварийная остановка, защитное вмешательство и штатные задачи
  • Полная трассировка решения: кто, когда и на основе какого локального состояния применил действие

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

ТребованиеЦелевое значениеОбоснование
Задержка между сегментамиОт минут до часовОграничения среды и физика канала связи
Автономная работа без связи24-72 часа и болееУдалённый сегмент не должен останавливать миссию без команды из центра
Гарантия доставкиКак минимум один раз с защитой от дублейПотеря критичных команд недопустима, но повторы нужно безопасно обрабатывать
Сходимость состоянияПосле каждого окна связиОбновления приходят не сразу, поэтому центр и край сходятся постепенно
Трассировка решенийПолная цепочка команд и результатовИнциденты приходится разбирать спустя часы или дни после фактического события

Высокоуровневая архитектура

Теория

Distributed Message Queue

Полезна для понимания асинхронной доставки, повторов, порядка событий и семантики доставки в разорванной сети.

Читать обзор

Высокоуровневая архитектура

пакеты команд -> автономное локальное выполнение -> согласование в окно связи
Центр -> политики -> релейная сеть -> шлюз
пакеты команд и передача в окно связи
Локальный кластер -> планировщик -> исполнители -> журнал
автономное выполнение без постоянной связи
Результаты -> канал -> согласование -> архив
возврат изменений и сходимость состояния

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

Архитектура разделяет контур , локальное выполнение и окно обратной синхронизации. Так система явно фиксирует , не зависит от постоянной связности и заранее понимает, когда можно безопасно запускать .

Пути записи и чтения

Пути записи и чтения

Как пакеты команд записываются, а состояние и результаты читаются и синхронизируются при экстремальных задержках.

Слой 1: Пакет команд. Центр собирает пакет команд с приоритетом, TTL и правилами безопасности.

Контрольные точки пути записи

  • Команды должны иметь ключ идемпотентности, класс приоритета и TTL.
  • Передача с промежуточным сохранением обязательна: доставка может занимать минуты и часы.
  • Локальный журнал событий нужен для безопасного повтора после сбоев.

В пути записи центр подготавливает пакет команд и отправляет его только тогда, когда канал действительно доступен. В пути чтения удалённый сегмент живёт от собственного состояния, а результаты возвращает обратно лишь в следующее доступное .

Согласование состояния и отказоустойчивость

Глубже

Синхронизация часов в распределённых системах

Нужна, чтобы понять логическое время, порядок событий и управление конфликтами в асинхронной репликации.

Читать обзор

Модель разрешения конфликтов

Обе стороны меняют состояние, пока канала нет, а узнают об изменениях друг друга с задержкой в часы. Правило объединения приходится фиксировать заранее: на чём строится и . Иначе после первого же окна связи центр и край разойдутся в трактовке истории, и спор будет решать случай, а не политика.

dominant_update = max_by(priority, logical_time)
if same_priority: merge_by_domain_rules()
ack_state = applied | queued | rejected
  • Приоритет безопасности: защитные команды всегда важнее штатных операций.
  • Идемпотентное применение: не позволяет повторной доставке испортить состояние.
  • Детерминированное объединение: оно нужно, чтобы обеспечить после каждого окна связи.

Контуры устойчивости

Надёжность здесь строится не на мгновенных подтверждениях, а на безопасных повторах, локальной автономности и полном журнале решений.

  • Повторная отправка: критичные сообщения идут по модели .
  • Контрольные точки: фиксируют прогресс и позволяют восстановиться после перезапуска.
  • Резервный сценарий: на удалённой стороне сохраняет безопасное поведение при потере центра.
  • Разбор после синхронизации: данные помогают объяснить, почему состояние разошлось и как система его восстановила.

Глубже

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

Отношение «произошло до» напрямую связано с причинностью: событие влияет на следующее только если между ними может пройти сигнал.

Читать обзор

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

  • Мышление в терминах RPC: попытка проектировать межпланетный контур как обычный синхронный API.
  • Нет локальной автономности: отсутствие режима работы без связи блокирует выполнение миссии.
  • Неформализованное объединение изменений: разные сегменты приходят к разным версиям состояния.
  • Повторы без удаления дублей: без и идемпотентности повторная доставка начинает портить данные.
  • Слабая наблюдаемость: без полной трассировки невозможно расследовать инцидент, который проявился лишь после долгой задержки.

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

  • Какие операции допустимо выполнять только при подтверждённой связи, а какие обязаны работать полностью локально.
  • Как устроено согласование состояния после восстановления канала и почему выбран именно такой подход.
  • Какие сигналы важнее всего для расследования: отставание синхронизации, накопившиеся повторы, отклонённые команды и защитные вмешательства.
  • Какой выбран между автономностью удалённого сегмента, точностью состояния и стоимостью канала связи.

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

Чтобы отмечать прохождение, включи трекинг в Настройки