Привет! Знаешь, метафора с фениксом – просто идеально подходит для систем, которые умеют сами восстанавливаться и перестраиваться после сбоев. Представь себе ядро, которое может “возродиться” в новом контейнере или кластере, когда один из компонентов выходит из строя, и при этом не теряет данные. Главное – сначала проектировать с учетом плавного ухудшения работы, а потом уже сделать восстановление автоматическим. Так вся система сможет возродиться из пепла намного быстрее, чем если бы пришлось все вручную исправлять. С какого аспекта дизайна начнем разбираться?

Отличный поворот! Давай будем рассматривать состояние как неизменяемый журнал, в который можно только добавлять записи, и который хранится в отдельном, реплицированном хранилище. Каждый узел подписывается на канал обмена информацией, получает последние записи и может восстановить свою локальную копию, воспроизводя их. Когда контейнер умирает, его реплика берет последнюю согласованную копию, а затем получает недостающие изменения из канала обмена информацией. Мы сохраняем код приложения без сохранения состояния, просто считывая данные из журнала, поэтому «возрождение» - это просто повторное подключение к тому же потоку. Самое сложное будет обеспечить, чтобы протокол обмена информацией гарантировал порядок и справлялся с перераспределением без потери записей. Готова проработать точную модель данных?