В статье представлена EPaxos* — упрощенная и исправленная версия протокола Egalitarian Paxos для распределенных систем. Классические протоколы вроде Paxos полагаются на выделенного лидера, что создает единую точку отказа и увеличивает задержку для удаленных клиентов. Egalitarian Paxos предлагает альтернативу без лидера, позволяя репликам совместно упорядочивать команды, сохраняя работоспособность при сбое до f из n=2f+1 процессов. Протокол обеспечивает быстрое выполнение команд за 2 задержки сообщений, если не более e=⌈(f+1)/2⌉ процессов выходят из строя.

Авторы отмечают, что оригинальный Egalitarian Paxos, несмотря на влияние на другие протоколы, страдает от сложности, неоднозначной спецификации и серьезных ошибок. EPaxos* решает эти проблемы с помощью более простого алгоритма восстановления после сбоев, строго доказанного корректности. Протокол также обобщает Egalitarian Paxos на весь спектр пороговых значений отказов f и e, где n ≥ max{2e+f-1, 2f+1}, что авторы доказали оптимальным.

• Обсуждение охватывает вопросы лидерства и консенсуса: Paxos и Raft, EPaxos, EPaxos, Multi-Paxos и Multi-Raft, а также их влияние на производительность и отказоустойчивость.
• Участники обсуждают, что такое "лидер" в контексте распределённых систем, и какие у него обязанности, включая упорядочивание транзакций и обеспечение отказоустойчивости.
• Участники также обсуждают, как различные протоколы консенсуса, включая Paxos и Raft, обрабатывают вопрос лидерства и как они влияют на производительность и отказоустойчивость системы.
• Участники также обсуждают, как различные протоколы консенсуса, включая Paxos и Raft, влияют на производительность и отказоустойчивость системы.
• Участники также обсуждают, как различные протоколы консенсуса, включая Paxos и Raft, влияют на производительность и отказоустойчивость системы.

Автор рассказывает о своем пути к любви к Erlang, начавшегося с непонимания базовых концепций программирования в восемь лет, когда столкнулся с выражением "X = X + 1" в BASIC, показавшимся ему математической ложью. В университете он столкнулся с такими же трудностями при изучении C, но продолжил учиться через практику и эксперименты. Переломный момент наступил, когда партнер по бриджу спросил, как суммировать числа от 1 до 10 без циклов, что привело его к открытию рекурсии в Prolog — математически чистого подхода, где описывалось "что" является, а не "как" вычислять.

Знакомство с Erlang произошло случайно на турнире по бриджу от шведского игрока, который описал его как функциональный язык для распределенных, отказоустойчивых систем. Автор был поражен возможностью простого обмена сообщениями между разными узлами без сложных протоколов, демонстрируя пример ping-pong на Erlang. Этот язык, сочетающий функциональность, распределенность и отказоустойчивость, стал тем, что он искал с детства — способом программирования, где математика говорит правду.

• @az09mugen отмечает полезность функции > cd .. в конце статьи за простоту и мобильную доступность.
• @az09mugen предполагает наличие пасхалки (easter egg) в этой функции.
• @Gleamball выражает благодарность за выступление и обмен информацией.

Инженер с опытом работы в Intel и Sun развенчивает популярные мифы о CPU-кэшах. Многие разработчики ошибочно полагают, что разные ядра могут иметь устаревшие значения в своих кэшах, а ключевое слово volatile в Java заставляет читать/писать данные напрямую в оперативную память. На самом деле, даже одноядерные системы подвержены проблемам конкурентности без правильных синхронизационных конструкций, а volatile-операции могут быть такими же быстрыми, как доступ к L1-кэшу (в 200 раз быстрее, чем к оперативной памяти), а не к основной памяти.

Современные CPU x86 поддерживают когерентность кэшей на аппаратном уровне через сложные протоколы, такие как MESI. Каждая строка данных в кэше помечается одним из состояний: Modified (измененные данные, источник правды), Exclusive (синхронизированные данные, нет копий в других кэшах) или Shared (синхронизированные данные, присутствуют в других кэшах). Понимание этих механизмов помогает лучше проектировать распределенные системы и избегать ложных представлений о производительности и конкурентности.

Here's my favorite practically applicable cache-related fact: even on x86 on recent server CPUs, cache-coherency protocols may be operating at a different granularity than the cache line size. A typical case with new Intel server CPUs is operating at the granularity of 2 consecut

Synadia и TigerBeetle совместно выделили $512,000 на поддержку Zig Software Foundation в течение двух лет. Synadia, создатель NATS.io, помогает крупным предприятиям проектировать и масштабировать архитектуры в облаке и на периферии, обслуживая клиентов в финансовой сфере, электронной коммерции, гейминге и промышленном IoT. TigerBeetle, финансовая база данных, разработанная на Zig с философией "TigerStyle", подчеркивает правильность, ясность и надежность.

Основатель Synadia Дерек Коллисон отметил, что Zig переопределяет возможности современного системного программирования благодаря своему подходу к контролю, производительности и простоте. Основатель TigerBeetle Йоран Дирк Гриф выразил уверенность, что Zig сыграет основополагающую роль в следующем поколении надежных распределенных систем. Обе компании разделяют видение предсказуемого, простого и заслуживающего доверия программного обеспечения, поддерживая Эндрю Келли и весь Zig-сообщество.

• Оценивали Rust, Zig и Ada/SPARK для критически важного ПО; Rust имеет поддержку корпорации и сообщества, но не применяется в кибер-физических системах.
• TigerBeetle получил $512k в течение 2 лет от Synadia и TigerBeetle, что вызвало вопросы о стратегии финансирования и приоритете языков.
• Обсуждение вылилось в обмен любезностями и техническими деталями, включая предположения о переходе на Zig и оставлении Rust без должной поддержки.

Fly.io столкнулся с крупнейшим сбоей в истории 1 сентября 2024 года из-за ошибки в Rust-коде их системы распределенного состояния Corrosion. Ошибка в if let выражении над RWLock привела к мгновенному и "заразному" deadlock, который парализовал все прокси-серверы платформы. Авторы подчеркивают, что распределенные системы — это "усилители взрывов": они распространяют данные по сети, а вместе с ними — и ошибки в системах, зависящих от этих данных.

Эта катастрофа стала следствием архитектурных решений Fly.io. В отличие от Kubernetes с его централизованной базой данных, Fly.io использует децентрализованную модель, где серверы являются источником правды о своих рабочих нагрузках. Чтобы масштабироваться по всему миру, они перешли от HashiCorp Consul и SQLite-кэшей к собственной системе Corrosion. Авторы предупреждают: если распределенная система еще не испортила вам выходные или не заставила не спать всю ночь, вы еще не до конца ее понимаете.

• Баг с if let и RWLock в Rust приводил к мгновенному глобальному дедлоку, что вынудило перейти от единого кластера к региональной двухуровневой схеме данных.
• Использование cr-sqlite (CRDT SQLite) для согласованности вызвало проблемы с nullable-колонками и масштабируемостью, что привело к критике выбора SQLite вместо Postgres.
• Gossip-протокол (SWIM) показал ограниченную масштабируемость (~2K-3K узлов), что потребовало иерархической структуры и разделения на региональные кластеры.
• Дизайн блога и отсутствие дат в статьях вызвали нарекания, но технические решения (регионализация, отказ от мгновенного глобального состояния) признаны необходимыми.

Проект OTP от команды gleam-lang предоставляет инструменты для создания отказоустойчивых многопоточных программ с использованием модели акторов. Реализация переносит мощные концепции Erlang OTP в экосистему языка Gleam, предлагая разработчикам современный подход к построению распределенных систем.

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

• Обсуждение началось с восторженного отзыва о Gleam и его преимуществах, но быстро перешло в сравнение с Erlang/OTP и обсуждение того, что такое actor-модель и как она справляется с распределённым состоянием.
• Участники обменялись мнениями о том, какие языки/подходы лучше подходят для BEAM-стека, и подняли вопрос о том, что именно делает Erlang уникальным и какие у него есть ограничения.
• Также было затронуто, что такое влияние имеет выбор языка на разработку DSL и встраивание в другие системы, и почему транспиляция в Lua не рассматривается как цель.
• В конце обсуждение сошлось на то, что выбор инструмента в конечном счёте сводится к личным предпочтениям и конкретному проекту.

LlamaFarm — это инструмент для локального развертывания AI-моделей, агентов, баз данных, RAG и пайплайнов за считанные минуты. Он позволяет запускать сложные AI-системы без облачной инфраструктуры, что особенно ценно для разработчиков, работающих с приватными данными или в условиях ограниченного интернета.

Проект упрощает интеграцию различных компонентов, таких как векторизованные базы данных и агенты ИИ, снижая порог входа в создание production-готовых решений. Это ускоряет эксперименты и развертывание, экономя время на настройке окружения.

• Поддержка децентрализации ИИ и локального запуска моделей для защиты приватности и снижения зависимости от крупных облачных провайдеров
• LlamaFarm позиционируется как инструмент для декларативной оркестрации локальных AI-систем (RAG, агенты, векторные БД) с акцентом на портативность и контроль над пайплайном
• Ключевые целевые аудитории — юристы, здравоохранение и госсектор, где критически важны безопасность данных и работа в изолированных средах
• Отличие от решений вроде LangChain или LlamaIndex — предоставление готового фреймворка для production, а не программируемых компонентов
• Вызовы: привлечение первых пользователей и упрощение процесса деплоя для широкого внедрения

NFS, созданный Sun Microsystems в 1983 году, остаётся фундаментальной технологией для распределённых систем спустя 40 лет после своего появления. К юбилею в сентябре 2025 года запущен сайт-архив, собравший оригинальные документы: технические спецификации, white papers, маркетинговые материалы и даже личные заметки разработчиков.

Среди ключевых участников проекта — Том Лайон, Брайан Павловски и Стив Клейман. Архив структурирован по разделам: исходные коды, конкурентные решения, фотографии. Отмечается, что альтернативный ресурс nfsv4bat.org содержит материалы после 1995 года, но его техническое состояние вызывает вопросы. Практический вывод: несмотря на возраст, NFS продолжает влиять на современные сетевые файловые системы, а его документация сохраняет ценность для инженеров.

• NFS широко используется в различных средах (от домашних сетей до крупных дата-центров) благодаря своей надежности, производительности и простоте.
• Основные проблемы NFS связаны с безопасностью (слабая модель аутентификации), зависимостью от стабильного сетевого соединения (при сбое сервера клиенты "зависают") и сложностями с масштабированием.
• Пользователи отмечают проблемы с альтернативами, такими как SMB на macOS, и часто предпочитают NFS для определенных рабочих нагрузок.
• В качестве альтернатив или дополнений упоминаются SMB, SSHFS, WebDAV, iSCSI, 9P и облачные решения (например, Amazon EFS).
• NFS остается ключевым решением для сетевого хранения в Unix-подобных системах, Kubernetes и других сценариях, где важна простота и производительность.

DBOS Transact для Go — это фреймворк для оркестрации устойчивых рабочих процессов, использующий PostgreSQL как единый источник истины. Он позволяет писать транзакционные приложения на Golang, где бизнес-логика выполняется атомарно и изолированно, а состояние автоматически сохраняется в базе данных. Это устраняет необходимость в отдельных системах управления состоянием или очередях, упрощая архитектуру и повышая надёжность.

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

• Сравнение с Temporal и другими системами оркестрации рабочих процессов, обсуждение подхода DBOS как библиотеки против внешнего сервиса, вопросы об идемпотентности и гарантиях обработки событий.
• Вопросы о технических особенностях DBOS: масштабируемость в кластере, версионирование рабочих процессов, приоритизация заданий, безопасность и варианты развертывания без исходящего сетевого доступа.
• Обсуждение архитектурных решений и альтернатив, таких как pgglow, и их интеграция с Postgres и клиентами на разных языках.
• Связь проекта с академическими исследованиями (DBOS OS) и его дальнейшее развитие, включая планы по поддержке новых языков и функциональности.
• Реакция сообщества: от положительных отзывов о простоте модели до скептических вопросов о гарантиях и практическом применении, а также упоминание частоты постов о проекте.

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

При изменении количества узлов перемещаются только данные, попадающие в зону между старыми и новыми узлами — примерно M/N элементов вместо всех M. Это обеспечивает стабильность системы: например, при выходе узла из строя его нагрузка равномерно распределяется между соседями, а не вызывает каскадный сбой. Алгоритм широко применяется в кеширующих прокси, распределённых базах данных и CDN для минимизации дисбаланса при масштабировании.

• Предложено использовать rendezvous hashing как более простую и универсальную альтернативу consistent hashing, не требующую виртуальных узлов и поддерживающую взвешенное распределение.
• Упомянуты различные реализации и применения хеширования: CRUSH в Ceph, Lamping-Veach алгоритм, кеш-ориентированная версия для SSD, простая реализация на Clojure.
• Обсуждаются стратегии минимизации перераспределения данных при изменении числа узлов: увеличение числа партиций, метод "power of 2 choices", кластеризация в rendezvous hashing.
• Отмечена опечатка в заголовке исходного поста ("Constitent" вместо "Consistent") и дан совет по её исправлению.
• Затронута историческая справка об основателе Akamai Дэниеле Люине и его трагической судьбе.

Разработчики сталкиваются с хаосом при отладке LLM-агентов в продакшене из-за фрагментации стандартов observability. Например, OpenAI предлагает детальные трейсы, но они привязаны к её фреймворку и не позволяют фильтровать отдельные спаны. New Relic поддерживает OpenTelemetry, но интерфейс громоздок для оперативного дебаггинга. Phoenix с OpenInference даёт богатые AI-специфичные спаны, но не полностью совместим с OpenTelemetry и не имеет SDK для Ruby, что критично для таких проектов, как Chatwoot.

Ключевая проблема — противостояние универсального OpenTelemetry (широкая поддержка языков, но базовые типы спанов) и специализированного OpenInference (богатые AI-типы, но слабая экосистема). OpenInference лишь поверхностно совместим с OpenTelemetry, приводя к «unknown» спанам при прямом использовании. Это вынуждает команды выбирать между созданием кастомных SDK, потерей контекста или сменой стека, замедляя разработку. OpenTelemetry остаётся прагматичным выбором из-за зрелости и кросс-языковой поддержки, но требует расширения семантики под AI-workflow.

• Разработка систем наблюдения (observability) для многозадачных LLM-агентов, включая метрики сложности задач и успешности выполнения.
• Обсуждение стандартов и инструментов (OpenTelemetry, Phoenix, Clickhouse) для отслеживания семантических ошибок и трассировки выполнения агентов.
• Критика подхода к оценке через ИИ из-за проблемы "курицы и яйца" и предложения использовать стандартные системы мониторинга.
• Вопросы о практическом применении длинных промптов не-техническими пользователями и динамической маршрутизации в агентах.
• Дискуссия о необходимости совмещения стандартных решений (реляционные БД) с OpenTelemetry для богатой семантики в распределённых системах.

Почему мы создаём Stategraph: состояние Terraform как проблема распределённых систем

Экосистема Terraform десятилетиями обходила фундаментальное архитектурное проблему: использование файловой семантики для решения задач распределённых систем. Результат предсказуем и болезнен.

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

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

Патология файлового состояния

Состояние Terraform — это проблема координации. Множество акторов (инженеры, CI-системы) должны одновременно читать и изменять перекрывающиеся подмножества состояния инфраструктуры. Вместо решений с тонкими блокировками и управлением параллелизмом Terraform использует глобальный мьютекс для JSON-файла.

Наблюдение: Вероятность конфликта блокировок растёт сверхлинейно с увеличением команды и количества ресурсов.

Несоответствие гранулярности:

• Текущая модель: чтение 100%, блокировка 100%, изменение 0.5%
• Фактическая потребность: чтение 3%, блокировка 3%, изменение 3%

Разделение файлов состояния не решает проблему, а перераспределяет её, добавляя сложность управления зависимостями между состояниями.

Состояние как граф: естественное представление

Состояние инфраструктуры по своей природе является направленным графом. Ресурсы имеют зависимости, образующие рёбра. Изменения распространяются по этим рёбрам. Terraform внутренне представляет состояние как граф, но на уровне хранения уплощает эту структуру в blob.

При нормализации состояния в графовую базу данных появляются естественные свойства:

• Изоляция подграфов: операции над несвязанными подграфами параллелизуемы
• Точные блокировки: блокировка на уровне ресурсов и зависимостей
• Инкрементальное обновление: вычисление минимального набора изменений через обход графа

Управление параллелизмом через правильные абстракции

Stategraph реализует проверенные паттерны распределённых систем:

• MVCC для неблокирующего чтения
• Write-ahead logging для сохранности данных
• Уровни изоляции транзакций

Традиционный подход:

Acquiring global lock… waiting

Stategraph:

Locking subgraph (3 resources)… ready

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

Результат: значительное улучшение пропускной способности при параллельной работе. Три команды могут одновременно применять изменения к независимым ресурсам.

• Предлагается заменить файловую систему Terraform на графовую базу данных для улучшения масштабируемости и устранения глобальных блокировок.
• Текущий файл состояния Terraform ценится за простоту и предсказуемость, но становится узким местом при работе с тысячами ресурсов и большими командами.
• Ключевая проблема — разделение состояния (splitting state) создаёт новые сложности, такие как зависимости между состояниями и необходимость оркестрации.
• Новое решение должно обеспечивать детализированное блокирование ресурсов, а не глобальную блокировку, и предоставлять возможности для запросов и отчётности.
• Обсуждаются вопросы управления доступом (RBAC) и миграции существующих крупных setup'ов в новую модель.
• Подход сравнивается с другими инструментами (Pulumi, Crossplane, Terraform Cloud), но фокус — на оптимизации именно модели Terraform/OpenTofu.
• Мнения разделены: одни видят в этом фундаментальный сдвиг, другие считают, что проблема вызвана антипаттернами в организации инфраструктуры.

• pgEdge теперь полностью Open Source
  Все ключевые компоненты (репликатор Spock, расширения Snowflake и Lolor) перелицензированы с проприетарной «pgEdge Community License» на свободную PostgreSQL License (OSI-одобрена).

• Что это даёт
  Можно свободно скачивать, модифицировать и использовать в продакшене без ограничений; код лежит в GitHub-репозиториях проекта.

• Где взять
  Исходники: github.com/pgEdge (репо spock, snowflake, lolor).
  Готовые образы и поддерживаемые сборки: облако, контейнеры, VM на сайте pgEdge.

• Зачем
  Мультимастер-дистрибутивный Postgres с минимальной задержкой и высокой доступностью теперь доступен сообществу без vendor-lock-in.

• Лицензия PostgreSQL (OSI) воспринята как «настоящая» open-source, в отличие от «фейковых» лицензий.
• Пользователи рады открытию кода, но опасаются, что гиперскейлеры «разграбят» проект.
• Маркетинговое описание вызывает раздражение: неясно, что за продукт, и «async multimaster» критикуют за потерю консистентности.
• Опытные пользователи спрашивают о реальной надёжности PgEdge и делятся багами (SIGILL в pgvector, месяц без реакции).
• Документация требует passwordless sudo и SSH, что отпугивает многих.

Как я решил проблему распределённой очереди через 15 лет

В Reddit всё — голоса, комментарии, посты — сначала попадало в RabbitMQ, потом в базу.
Очередь давала горизонтальное масштабирование, шейпинг и cron, но падала: задача могла исчезнуть после взятия из очереди или при краше брокера. Нужны были долговечные очереди, сохраняющие состояние в Postgres.

Сегодня это реализуется через долговечные workflow: каждый шаг чек-поинтится в БД, задачи запускаются параллельно, при падении продолжаются с последнего сохранённого места.

• Пост вызвал спор: одни хвалят вводный уровень, другие ждут разбора «распределённой» сложности и конкретного решения.
• Критика: заголовок обещает «как я решил», но статья не формулирует проблему и не показывает шаги решения.
• Автор подменяет «очереди» «устойчивыми воркфлоу»; читатели считают, что это разные вещи.
• RabbitMQ 15-летней давности обвинили в отсутствии надёжного бэкапа состояния; Kafka, наоборот, приводят как пример «и быстро, и надёжно», но её обвиняют в перекладывании сложности на потребителя.
• Главная идея DBOS: устойчивость без внешнего координатора и без переписывания кода под async-рантайм.

Алгоритм CRDT для совместного текста

Каждый символ получает уникальный id: site (идентификатор узла) и clock (локальный счётчик, увеличиваемый после каждой операции), а также parent — указатель на предыдущий символ.

• Вставка
  parent ставится на символ перед точкой вставки (null — в начало). Порядок символов задаётся прямым обходом дерева: родители идут раньше потомков.

• Сортировка при одинаковом parent
  Сначала по убыванию counter, затем по site. При вставке перед символом с тем же parent берём его counter + 1.

• Удаление
  id символа попадает в множество удалённых (tombstone). Значение можно забыть, но позиция нужна для корректного порядка.

Оптимизации

1. Последовательные вставки одного узла объединяются в блок: массовая вставка стоит как одна операция.
2. Блоки хранятся в отсортированном массиве; вставка — O(log n) без явного дерева.
3. Удаления группируются диапазонами по site и clock.

Плюсы и минусы

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

Интерактивный пример
Четыре пира, задержка сети, редактирование кликом. Исходник — crdt-text-buffer.js.

Полезные ссылки

• josephg.com/blog/crdts-go-brrr/ — эффективная реализация.
• archagon.net/blog/2018/03/24/data-laced-with-history/ — деревья и сборка мусора.

• Обсуждали RGA — CRDT-алгоритм для списков и текста, который Automerge раньше использовал до перехода на FugueMax.
• У RGA есть редкая проблема: при вставке элементов в обратном порядке у разных пользователей возникает чередование.
• Упомянули Eg-Walker — новый подход от Loro.dev, который вызвал интерес у участников.

Raft — алгоритм консенсуса, проще в понимании, чем Paxos, с той же отказоустойчивостью и производительностью. Он разбит на независимые подзадачи и покрывает все практические аспекты.

Консенсус — соглашение нескольких серверов о значении; решение становится окончательным. Кластер из 5 машин работает, пока живы ≥3. Используется в реплицированных конечных автоматах: каждый сервер имеет журнал команд, которые консенсус выстраивает в одинаковом порядке, чтобы все автоматы оставались синхронизированы.

Визуализации

• RaftScope — интерактивная пятисерверная модель в браузере.
• The Secret Lives of Data — более мягкое, пошаговое объяснение.

Публикации

• Основная статья: In Search of an Understandable Consensus Algorithm (USENIX ATC’14 Best Paper).
• Диссертация Диего Онгаро: расширенное описание, формальная спецификация TLA+, упрощённое изменение состава кластера.
• Дополнительные работы: верификация (Woos et al., 2016), фреймворк Verdi (Wilcox et al., 2015), автогенерация кода (Evrard & Lang, 2015), анализ Raft (Howard, 2014–2015).

Доклады

• John Ousterhout, UIUC Distinguished Lecture, 2016 (видео, слайды).
• Jin Li, Dr. TLA+ Series, 2016 (видео, слайды).

• Обсуждение показало, что Raft сделал распределённый консенсус понятным и реализуемым, в отличие от Paxos.
• Участники делятся опытом: кто-то использует Raft для отказоустойчивой репликации состояния игры, кто-то — для промышленных систем.
• Упоминаются альтернативы и тонкая настройка: спектр дизайнов репликации Алекса Миллера, Viewstamped Replication, Consul-подход с батчами.
• Разобраны нюансы выборов лидера, сетевых разделов и гарантий «одной записи».
• Google использует и Paxos (Spanner), и ранние внутренние варианты VR; Raft тоже реализуют повсеместно.

%PDF-1.3  
5 0 obj  
<< /Length 737 /Filter /FlateDecode >>  
stream  
xڵUKO0WHc;>@b% eiEд;~4PV\\V=رy|̸0q"e\\%\*H-YD 9Ze2& Őg¨Ҡ3D=>mErX\\/ )=9>8IrA3H³J
>\['\[R{89CRԿ8EXDMkUĿKRcRIX|m8vcM"mc-jjb|4ӍYJ+{A=4e16}{gρ\`sa(w 1}@+\\\\
pȜc5AKt!}'n\\\[M8pe$ZQdP\`N\]͚Lۛ쨣Hg6GsBxfܱ ?jQ<
ߵT
{P̯?c)n\[y%̲OprN5~qxvHrz:T:vT7Q Iɩw4fQ+8V\[ %ͅt-x^\]z\]>ä́^ukK!zvXh#O&gCT fqkk5  
endstream  
endobj  

4 0 obj  
<< /Type /Page /Contents 5 0 R /Resources 3 0 R /MediaBox \[0 0 595.276 841.89\] /Parent 12 0 R >>  
endobj  

1 0 obj  
<< /Type /XObject /Subtype /Form /FormType 1 /Matrix \[1 0 0 1 0 0\] /BBox \[0 0 143 73\] /Resources << /ProcSet \[ /PDF \] /ExtGState << /R8 13 0 R /R4 14 0 R >> >> /Length 15 0 R /Filter /FlateDecode >>  
stream  
xYn-;mVzn2
#m@sǀ\\R#E?ſ߿GJm>k?kZ\_cߏҾv>K~Rr~>8J?3x>jK\_cxy+e\*o뫔/|篲g=|jv~PUOWW9K<+;><c϶\_kQZag<xk쉳q?(w ֝ Ip\_\`; }T?q\_ugnkQy߹uei<qw;a=pL\]'j\*#@=k5BLv~&4<yyZ:1y!&F|@yQU,8} 7q=6Aݶ\*g95\]\\T7Ky1PO9yb~nw.ڸQ~QzP· DZs«rUC\] 0C!K83{0\\ЮѪ\]C!S s+B/qҺsCrvks6}MYX=HPпC<Ӈs3?3Ϸa!9OM·ΎXŞ8׉|h'湻.3>-C @:k1>@y˹C\*X>p"ۂ @owԩv!X8a5-z-:Ʋyӛ2=;d\*繲9oAkY\_;,,=ᰐ3>R;"8l=ׄ>@>xݞ\\FyV!vY\]1w1ޘML9JJv9&#qzGmr>9E/ϓdྟ\_ov9, \]:$玚"#jyH灈Dsd@f"T~Gf\[tV">Ɵ
Wћňq\[qJ\[$V,KD)Q!xg\\ܚtpv7ҘBudm.$0#HKg8G  V5lC/u9 l{ihs
9C ;ajB٪> t|^P4vfAu$F0P ʥ.hDA9GyhȑtR 7 ښ^՟66:lĕ׮b<Ү.$Jɻ(Ʋ~hAόBs~Q^|j9Xꂥ.~u:,%MT(zϰL:"(:t4݇/vk|eQq}t%I9jBY9L9\]N& #QK;bggwcYjUh\\PM8-Z%d3x~خ"+,Π£n zo~?^'-BZ}C0^bUq\[$"Jދ鳣&mu(0AP/dm{ę3>rP1-$$2đ7;TƃAg\\R$1#) mh 3~.b8fK'C/x9#
\*N,}v89\`
sb3\`8 \[S\*7g,v?3?ܷ ʾJ \[A?tSKBs\`y$Xu4ٟ|
HdoܥfaDX%39.L=a\*0 #RnI0葡L&u;Ce+JMI\_Z^8tT0wJ#g|q2!3mԹ3"O~e;,D)Rı΅P# \[@y/.ϹG6s:t? eMf,\_B;PAXHG뇫b/+D<cflI.:eLט/l'B-HR \]$agra;{9rrs;UPymX4)iEf㕇qjS(;bedȑLtˆ &>߫HŖ)8퇀ˡeGA 9ݹ.\_U(61,%#t$gC&ʄ+SA)SHݍ\_NE%d̨
R΀Zpf ?dAH,͜c\*g(|@'13sdg\]\[Lw"{"hx<.#ob@E4$ i=ǃ࿦4#{,<Y f^a&mVFS$dG2 hAB:Z{Q\_F т1>P$9PA<X{TdMBt=\\{9=CvOtO&E^
JwM6'\]!9V|rɟTEyQX/> -|0&u$)i5,yץ}ceCGw\_ړm$)5 |>s"dؒdthjziYF%\\~ˤyKΈ+bK0g\\qtOT%,\*\_\\~9pϊBpCkB+@$\_s}Op^5efJDM\]-n. p)Rd7>Od0 \`J7Dmbs}t|)\`n3h\[V!ueX Cװd\`~>G:EͰ6q@cvKl |6\`ldwBÉo T=Iiw#Ar#tV:ܒA\`;\_J\`樼:4{OSH!H8!
c3vavg{rmS<3,r8!UD0^0 1\`\`Nz\`{ſb$R\`wZ5~9kf\*OpZ |=,
w$M x%;L%6R\_ :BYqOHRŬ.sw5g+
(%h1y6\*kyVES\]@E,;DFxKY1oEnSeKz&Ƙ':rxwEb1\\!^pX\]=}2x7\_^v+\*~EU;A9-
IIKTP,c(0v4@,8f qIwy-<@!Yg Վ.S4 2E\]AgG<dXY3<9\_5U>2|kӏ4—^\[Gbڗa@h<)Y&\*bpG'td:\*o}탌Otda 2hyL\\Xdif\\ۀ-ZS#2 &
h\\Yo~!7z8 LuÅCP\]k?}C0 F>Jз;,) Qb\[:ӬT\_n@@!=\`5^/Ed/pveU&lB؂>TVD-r3: \]pLE@lvIMd5Q{yœܰ'T~a
 >x @u\\8qhjqc 7 E \*\]Jʭ\`(2/ W%Wi:=PRB,+$ >;9HR\[,fßfRDʽdmܺ/<y
E%<{׌8@Hшxvi}ό\_HEE-"-XJt6m}Fn{~
gӼgŌ0~s|kW|b4wH5ﱥמo ڵ7JH@~(abe3Ы-nWNjNR1,dg|LBq+&\*BWiƥԕBJiʲcؽkl➱7&x\\B 5q.9:\]mRף>aFybU{r@׌aR=B~Q2p\\kRgƻ}2aax\`5Vq4\[0?&G'K$\[TѸQv&xZ Y/ឨ {^zVE\\̵Pp\] O;5k-5C+ 1.p{|do@սV,L>{X&ևɓB|CR
/\*3>.sMX!G!P(8Z/ 
o}X< K)!?'Jx-->c TAi\_""GAyK~yw낇35>yR#?Grig\\3  ·0\\,sE 'Ss,GP83nbby@zqy\[@gL>+?O(hX={UL;m dI! FMV70\[w\_fW+E1sxbP,#\[BWpo\*I\[b"򉒽kD,?zoqr{BC-礌\*Y!Ԫ\*96͑k.?Ŕ(%z,MJйL0A:/{<+b<,@W>PmEkxX<bLqSDZMY=êbOÚֈsAe8CTuv
Yq\]Ѷ7pp 4
' =LLo@xĸ?AӝEVXEaԲ5

• Участники вспоминают Джо Армстронга и его ссылки на работу Джима Грея о Tandem.
• Отмечают, что Erlang/Elixir были технологически опережающими, но не стали массовыми.
• Идеи Erlang постепенно проникают в .NET и Java через Akka и Orleans.
• Удивляются, почему Erlang не используется даже в новых коммутаторах Ericsson, хотя был создан для них.
• Считают, что полное внедрение Erlang угрожает существующим бизнесам и рабочим местам, а рынок предпочитает «хуже, но дешевле».

Elixir-миф #1: «Let it crash»

Фраза «let it crash» вводит в заблуждение: звучит так, будто приложение падает, хотя речь всегда идёт об отдельном процессе, который супервизор мгновенно перезапустит. Приложение при этом живёт.

Проблема: процессы связаны с реальными вещами — сокетами, HTTP-запросами, файлами, БД. Пример LiveView:

def handle_event("import_data", %{"data" => data}, socket) do
  Enum.each(data, &create_item/1)
  {:noreply, socket}
end

Код упадёт, если:

• имя события не совпадёт;
• нет ключа "data";
• data не список;
• ошибка в create_item/1.

Первые три случая — скорее баг фронтенда, падение допустимо. Но последний — ошибка валидации одного элемента, и из-за неё весь веб-сокет пользователя рвётся, UI пропадает. Это плохой UX.

Что делать вместо «let it crash»

1. Валидируй вход до бизнес-логики.
2. Возвращай ошибки пользователю, а не падай.
3. Перезапускай только то, что действительно сломалось (например, соединение с БД), а не весь контекст пользователя.

Слоган лучше переформулировать:
«Не позволяй падать — позволяй исцеляться».

• «Let it crash» — это не призыв игнорировать ошибки, а концепция быстрого восстановления через дёшёвые процессы и деревья супервизоров BEAM.
• Слоган выглядит провокационно, но подразумевает, что система спроектирована так, чтобы падение одного процесса не рушила всё приложение.
• Ключевой источник — докторская диссертация Джо Армстронга «Making reliable distributed systems…», которую участники считают обязательной к прочтению.
• Перезапуск не решает фундаментальные проблемы (отсутствие конфигурации и т. д.), но помогает с транзиентными сбоями и временными условиями.
• Если ошибка повторяется, дерево супервизоров поднимает её всё выше, пока приложение либо восстановится, либо окончательно упадёт.