Межпланетная распределённая система ломает почти все привычные допущения о сети: задержка измеряется минутами и часами, окна связи редки, а разрыв канала считается нормальным режимом работы, а не исключением.
Кейс помогает спроектировать локальную автономность, передачу с промежуточным сохранением, детерминированное согласование состояния и планирование вокруг редких окон связи и жёстких ресурсных ограничений.
В интервью и архитектурных обсуждениях он полезен тем, что заставляет пересмотреть скрытые допущения о времени, координации и управлении системой в среде, где подтверждение приходит слишком поздно.
Окна связи
Канал доступен редко и ненадолго, поэтому отправку команд, подтверждения и выгрузку результатов нужно проектировать вокруг этих окон, а не поверх них.
Локальная автономность
Удалённый сегмент должен безопасно принимать решения без центра, иначе любая потеря связи превращается в остановку миссии.
Детерминированное согласование
После восстановления связи обе стороны должны одинаково объединять изменения, иначе расхождения будут накапливаться после каждого обмена.
Приоритет безопасности
Аварийная остановка, защитные команды и ручные сценарии вмешательства обязаны иметь явный приоритет над обычными задачами.
Межпланетная распределённая вычислительная система заставляет проектировать сервис так, будто постоянной связи не существует. Здесь задержка измеряется минутами и часами, связь появляется лишь в отдельные , а сеть с большими задержками , а не аварией. В такой среде нужен : удалённый сегмент обязан безопасно выполнять миссию даже тогда, когда подтверждение от центра придёт слишком поздно.
Источник
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 и правилами безопасности.
Контур политик
Слой 2проверка и подпись
Контур политик проверяет пакет и подписывает его перед отправкой.
Релейная сеть
Слой 3промежуточное сохранение
Команды идут через сеть, рассчитанную на большие задержки, с повторами и защитой от дублей.
Локальная очередь
Слой 4приём на стороне узла
Орбитальный шлюз принимает пакет и помещает его в локальную очередь исполнения.
Локальный журнал событий
Слой 5неизменяемая запись
Команда фиксируется в устойчивом журнале для автономного исполнения и безопасного повтора.
Контрольные точки пути записи
- •Команды должны иметь ключ идемпотентности, класс приоритета и TTL.
- •Передача с промежуточным сохранением обязательна: доставка может занимать минуты и часы.
- •Локальный журнал событий нужен для безопасного повтора после сбоев.
В пути записи центр подготавливает пакет команд и отправляет его только тогда, когда канал действительно доступен. В пути чтения удалённый сегмент живёт от собственного состояния, а результаты возвращает обратно лишь в следующее доступное .
Согласование состояния и отказоустойчивость
Глубже
Синхронизация часов в распределённых системах
Нужна, чтобы понять логическое время, порядок событий и управление конфликтами в асинхронной репликации.
Модель разрешения конфликтов
При двусторонних обновлениях с большой задержкой система должна заранее формализовать, как использует и , чтобы обе стороны одинаково трактовали историю изменений.
dominant_update = max_by(priority, logical_time) if same_priority: merge_by_domain_rules() ack_state = applied | queued | rejected
- Приоритет безопасности: защитные команды всегда важнее штатных операций.
- Идемпотентное применение: не позволяет повторной доставке испортить состояние.
- Детерминированное объединение: оно нужно, чтобы обеспечить после каждого окна связи.
Контуры устойчивости
Надёжность здесь строится не на мгновенных подтверждениях, а на безопасных повторах, локальной автономности и полном журнале решений.
- Повторная отправка: критичные сообщения идут по модели .
- Контрольные точки: фиксируют прогресс и позволяют восстановиться после перезапуска.
- Резервный сценарий: на удалённой стороне сохраняет безопасное поведение при потере центра.
- Разбор после синхронизации: данные помогают объяснить, почему состояние разошлось и как система его восстановила.
Глубже
Лэсли Лампорт и распределённые системы
Отношение happens-before напрямую связано с причинностью: событие влияет на следующее только если между ними может пройти сигнал.
Риски и типовые ошибки
- Мышление в терминах RPC: попытка проектировать межпланетный контур как обычный синхронный API.
- Нет локальной автономности: отсутствие режима работы без связи блокирует выполнение миссии.
- Неформализованное объединение изменений: разные сегменты приходят к разным версиям состояния.
- Повторы без удаления дублей: без и идемпотентности повторная доставка начинает портить данные.
- Слабая наблюдаемость: без полной трассировки невозможно расследовать инцидент, который проявился лишь после долгой задержки.
Что важно проговорить на интервью
- Какие операции допустимо выполнять только при подтверждённой связи, а какие обязаны работать полностью локально.
- Как устроено согласование состояния после восстановления канала и почему выбран именно такой подход.
- Какие сигналы важнее всего для расследования: отставание синхронизации, накопившиеся повторы, отклонённые команды и защитные вмешательства.
- Какой выбран между автономностью удалённого сегмента, точностью состояния и стоимостью канала связи.
Связанные главы
- Distributed Message Queue - Передача с промежуточным сохранением, повторы и семантика доставки для каналов с экстремальной задержкой.
- Синхронизация часов в распределённых системах - Логическое время, порядок событий и контроль конфликтов при огромных сетевых задержках.
- Консенсус: Paxos и Raft - Где консенсус действительно нужен, а где разумнее опираться на согласование состояния после восстановления связи.
- Local First (short summary) - Локальная автономность и работа без постоянного подключения в системах с редкой или нестабильной связью.
- Лэсли Лампорт и распределённые системы - Причинность и отношение happens-before как основа детерминированного объединения изменений.
- Hacking the System Design Interview - Оригинальный кейс и логика обсуждения архитектурных компромиссов для такой системы.