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.
- Называет реальные риски, диагностику и критерий корректности.
- Связывает ответ с текущей документацией и миграционными ограничениями.