ElixirMiddleSystem design

Как проектировать supervision tree для fault-tolerant системы?

Supervision tree проектируется по принципу «пусть падает»: каждый процесс с независимым жизненным циклом — под отдельным supervisor, стратегия выбирается исходя из зависимостей между дочерними процессами (one_for_one, rest_for_one, one_for_all).

Проектирование Supervision Tree для fault-tolerant систем

Supervision tree — иерархия процессов-супервизоров и рабочих процессов. Главный принцип: let it crash. Вместо защитного программирования процессы позволяют себе упасть, а supervisor перезапускает их в известном чистом состоянии.

Базовая структура

defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      MyApp.Repo,
      {Registry, keys: :unique, name: MyApp.Registry},
      MyApp.Cache,
      MyAppWeb.Endpoint
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

Стратегии supervisor

  • :one_for_one — при падении дочернего процесса перезапускается только он. Используется, когда дочерние процессы независимы друг от друга.
  • :one_for_all — при падении любого процесса перезапускаются все. Нужно, когда все дочерние процессы жёстко связаны и не могут работать без друг друга.
  • :rest_for_one — при падении процесса перезапускаются он и все процессы, определённые после него в списке. Для pipeline-зависимостей.

Практический пример: вложенные supervisors

defmodule MyApp.WorkerSupervisor do
  use Supervisor

  def start_link(opts), do: Supervisor.start_link(__MODULE__, opts, name: __MODULE__)

  def init(_opts) do
    children = [
      {MyApp.TaskQueue, []},
      {MyApp.WorkerPool, size: 10}
    ]
    # rest_for_one: если упадёт TaskQueue, WorkerPool тоже перезапустится
    Supervisor.init(children, strategy: :rest_for_one)
  end
end

defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      MyApp.Repo,          # БД должна стартовать первой
      MyApp.Cache,         # Кеш после БД
      MyApp.WorkerSupervisor  # Воркеры после инфраструктуры
    ]
    Supervisor.start_link(children, strategy: :one_for_one, name: MyApp.Supervisor)
  end
end

DynamicSupervisor для динамических процессов

Когда количество дочерних процессов заранее неизвестно (например, по одному процессу на пользователя):

defmodule MyApp.SessionSupervisor do
  use DynamicSupervisor

  def start_link(opts), do: DynamicSupervisor.start_link(__MODULE__, opts, name: __MODULE__)

  def init(_opts), do: DynamicSupervisor.init(strategy: :one_for_one)

  def start_session(user_id) do
    spec = {MyApp.Session, user_id: user_id}
    DynamicSupervisor.start_child(__MODULE__, spec)
  end
end

Параметры restart и max_restarts

defmodule MyApp.Worker do
  use GenServer,
    # :permanent — перезапуск всегда (по умолчанию)
    # :transient — только при аварийном завершении
    # :temporary — никогда не перезапускается
    restart: :transient
end

# Supervisor с настройкой лимита:
Supervisor.start_link(children,
  strategy: :one_for_one,
  max_restarts: 3,    # не более 3 рестартов
  max_seconds: 5      # в течение 5 секунд
)

Подводные камни

  • Слишком плоский tree (всё под одним корневым supervisor) — одна постоянно падающая задача сработает max_restarts и убьёт все другие процессы.
  • Слишком глубокий tree с :one_for_all на каждом уровне — одна мелкая ошибка рестартует половину системы.
  • Порядок дочерних процессов важен: Repo должен стартовать до процессов, которые делают запросы к БД; неверный порядок — краш при старте.
  • DynamicSupervisor не имеет ограничения на количество детей по умолчанию — утечка через неконтролируемое создание процессов приведёт к OOM.
  • Использование :temporary с handle_info/2 для бизнес-логики — при краше состояние теряется без возможности диагностики.
  • Инициализация GenServer с тяжёлыми операциями в init/1 (HTTP-запрос, загрузка данных) блокирует supervisor на время init — используйте handle_continue/2.
  • Не используя Registry + DynamicSupervisor вместе, невозможно надёжно найти процесс по ключу после его перезапуска.

Common mistakes

  • Отвечать определением без production-сценария.
  • Не называть runtime boundary, security boundary или failure mode.
  • Игнорировать версию API, observability и тестовую проверку.

What the interviewer is testing

  • Объясняет механизм своими словами и без выдуманных API.
  • Называет реальные риски, диагностику и критерий корректности.
  • Связывает ответ с текущей документацией и миграционными ограничениями.

Sources

Related topics