title: Конспект материала 28 — awesome-distributed-systems (theanalyst) source: https://github.com/theanalyst/awesome-distributed-systems author: курируемая подборка классики распределённых систем «on architecture itself rather than code» (bootcamp-теория, книги, первоисточники-статьи, курсы, блоги) конспект: подготовлено 2026-09-18, TASK-45.32; README прочитан целиком (83 ссылки, 8 разделов); топ-5 отобраны и прочитаны полностью — 2 статьи конференций (Dynamo SOSP'07, 16 стр.; Dapper, 14 стр.) + 2 инженерных поста/доклада (Hodges 2013, Hamilton USENIX LISA'07) + сайт и визуализации Raft статус: P3-источник «после секций», но это единственная подборка, где в одном месте лежат первоисточники (Dynamo, Dapper, Hamilton, Raft) — то, на что ссылаются все остальные конспекты. Папку Books/Courses пропускаем сознательно (DDIA-глубина уже законспектирована, тяжёлые курсы не успеть до слотов), топ-5 смещён в «первоисточник + операционный практический слой»

Материал 28: awesome-distributed-systems — индекс и топ-5

Из всех просмотренных подборок эта — самая «теоретическая» по духу: никаких кейсов компаний и шпаргалок, а канон распределённых систем — от Fallacies и CAP до первоисточников Dynamo/GFS/Paxos и инфраструктуры наблюдаемости (Dapper, Jepsen). Для нашей секции (крупноблочная схема + отказоустойчивость) ценность не в «прочитать всё» — почти вся теория списка уже лежит в KB §5–§7 и DDIA-конспектах, — а в первоисточниках с числами и формулировками, которые придают ответам вес: «так это описано в Dynamo» звучит иначе, чем «вроде есть такой приём». Плюс два текста закрывают слой, которого не хватало другим конспектам: операционная мудрость (Hodges, Hamilton) и наблюдаемость (Dapper).

1. Как устроен источник

2. Критерии отбора топ-5

1. Не дублировать уже покрытое. Механики Dynamo (quorum, векторные часы, sloppy quorum, Merkle) уже в KB §5/§7 (Alex Xu гл. 6, DDIA); The Log — топ-5 материала 27; деградация (Netflix/Brewer) — материал 26; Jepsen — материал 33; лекции Клеппмана — материал 32. Поэтому Papers-канон берём только там, где статья даёт новое поверх конспектов (рамка решения, числа, формулировки), а остальные слоты отдаём непокрытым слоям: эксплуатация, наблюдаемость, практический словарь.
2. Прямая релевантность брифу: крупноблочная схема сервиса + отказоустойчивость + «говорим эксплуатацию всегда» (KB §10). Каждый пункт закрывает конкретный вопрос интервьюера: «почему AP, а не CP», «что будет, если упадёт мастер», «как вы это эксплуатируете», «как вы это наблюдаете».
3. Скорость поглощения под слоты 18–22.09: все топ-5 читаются суммарно за 3–4 часа, без курсов и книг; две статьи — классика, которую цитируют сами конспекты KB.

3. Топ-5

3.1 Dynamo (Amazon, SOSP'07) — первоисточник AP-дизайна: рамка решения, а не механики

Выжимка. Сами механики (consistent hashing с виртуальными нодами, N/R/W, векторные часы, sloppy quorum, hinted handoff, Merkle-антиэнтропия, gossip-членство) у нас уже законспектированы (KB §5–§7) — читать статью стоит ради рамки, в которой они выбраны. (1) Бизнес-кейс как требование: «покупатель должен иметь возможность положить товар в корзину, даже если диски отказывают, маршруты флапают, а ДЦ сносит торнадо» — корзина always-writable, и из этого единственного требования выводится весь дизайн (AP вместо CP). Урок для секции: сначала фиксируешь, что дороже терять — запись или чтение, остальное выводится. (2) SLA измеряется на 99.9-перцентиле, а не на среднем: клиенты с длинной историей (персонализация) — самые нагруженные, медиана их не видит; 99.9, а не 99.99 — сознательный cost-benefit выбор. (3) Типовая конфигурация (N, R, W) = (3, 2, 2), SLA «99.9% чтений/записей быстрее 300 мс»; p99.9 ≈ 200 мс — на порядок выше среднего (диуральный паттерн нагрузки), поэтому оптимизации вроде балансировки write-координаторов делались именно под p99.9. (4) Availability и durability не синонимы: растёшь W — прочнее durability, но чаще отказываешь записи (больше реплик должны быть живы); трейдофф проговаривается явно. (5) Операционные мелочи: нода «отвалилась» ≠ выбыла из кольца (членство меняет администратор, gossip распространяет — иначе флапающий узел ребалансирует кластер); hinted-реплика лежит в отдельной локальной БД и доставляется по восстановлению; buffered writes сглаживают пики дисковых операций.

Что брать на секцию. - Готовая формулировка выбора AP: «как в Dynamo — корзина должна писаться всегда, поэтому читаем возможно устаревшее и мирим версии; консистентность жертвуем осознанно». Это ответ на «почему не просто Postgres master-slave». - «SLA на p99.9, потому что самые ценные клиенты — самые тяжёлые» — зрелая реплика про перцентили (стыкуется с KB §10 и Young Bloods §3.3). - Числа: (3,2,2), 300 мс SLA, p99.9 ≈ 200 мс «на порядок выше среднего» — три цифры, которые делают ответ про кворум конкретным. - «Availability ≠ durability» при настройке W — тонкость, которую редко называют; хорошо звучит в блоке про шардирование/репликацию.

3.2 Raft: raft.github.io + The Secret Lives of Data — механика «упал мастер» за 30 минут

Выжимка. Сайт-дом консенсуса (переехал с raftconsensus.github.io): описание алгоритма в одном абзаце («эквивалентен Paxos по отказоустойчивости и производительности, но разложен на независимые подзадачи — выборы, лог, безопасность»), модель replicated state machine (клиенты думают, что общаются с одной надёжной машиной, хотя кластер из 5 переживает отказ 2 узлов) и интерактивная визуализация RaftScope прямо на странице. Рядом — управляемая пошаговая визуализация The Secret Lives of Data: на живом примере «зарегистрировать в логе set x=3» показывает, как узел с полным логом становится кандидатом, набирает большинство голосов (термины-эпохи растут при каждом таймауте heartbeat), реплицирует записи и коммитит их, что происходит при партиции и почему узел с устаревшим логом не может выиграть выборы. Консенсус гарантирует: если одна реплика применила «set x=3» как n-ю команду, ни одна другая не применит другую n-ю — отсюда идентичные последовательности состояний на всех узлах. Для нас это закрепление механики KB §7 (эпоха/терм, два голосования, кворумы DDIA гл. 10) в виде наблюдаемой картинки, а не нового знания.

Что брать на секцию. - Ответ на «что будет, если упадёт мастер БД/координатора»: «мастер — не SPOF, если за ним консенсус: термины растут при каждом таймауте heartbeat, кандидат с более свежим логом побеждает, кворум коммитит; при потере кворума кластер молчит, но не врёт» (последняя фраза — свойство safety консенсуса: не прогресс, но никогда неверный результат). - «Почему 5 узлов, а не 4»: прогресс при любом большинстве, 2 из 5 можно потерять; чётный размер не добавляет отказоустойчивости, только латентность. - Raft как ответ на «зачем ZooKeeper/etcd»: Raft — тот протокол, что крутится внутри etcd/консула; стыкуется с KB §7 (координационные сервисы, fencing tokens). - Время на подготовку: RaftScope + Secret Lives ≈ 30 минут на глазах — лучший ROI из всего списка.

3.3 Notes on Distributed Systems for Young Bloods (Hodges, 2013) — словарь зрелых ответов

Выжимка. 16 уроков инженера-практика (Google/Swiss Systems, рецензенты — Coda Hale и др.); ни одна из «шпаргалок» списка не даёт столько готовых формулировок на квадратный метр. Ключевое: (1) распределённые системы отличаются вероятностью частичного отказа, а не латентностью — «отправить на обе машины и ретраить» — маркер неопытности; отказ unlock распределённого мьютекса встраивается в протокол, а не роняет процесс. (2) Backpressure — базовый строительный блок: сигнал отказа от сервера клиенту, ограничение ресурсов при перегрузке; без него — каскадные отказы или тихая потеря сообщений. (3) Partial availability — «найти способ быть частично доступным»: поиск отдаёт то, что успел собрать за бюджет; для личных сообщений лучше уронить сервис для малого процента пользователей, чем молча терять письма у всех; размечать failure domains. (4) Метрики vs логи: «логи врут» — редкие классы ошибок раздувают файл и уводят расследование; «ты не Шерлок, пока метрики не подтверждают историю». (5) Перцентили, не средние: «я не видел распределённой системы, где латентность — колокол; среднее ведёт к неверным решениям». (6) Feature flags для миграций инфраструктуры: замена хранилища шагами «двойная запись → чтение-сравнение → перевод чтения» с ручками отката; «много версий инфраструктуры — норма, а не исключение». (7) Выбирай пространство ID осознанно: чем больше идентификаторов нужно до данных, тем больше вариантов партиционирования (кейс Twitter API v1: твит адресуем только tweet id → для партиционирования по пользователю нужен lookup-сервис; а включи user id в tweet id — потеряешь k-сортируемость). (8) CAP — инструмент критики дизайна, а не принцип построения; «из C, A, P нельзя выбрать CA». Плюс: координацию машин — минимизировать; «it's slow» — самая тяжёлая отладка; кэш нельзя писать обратно в персистентное хранилище; компьютеры мощнее, чем ты думаешь; выделяй сервисы вместо библиотек.

Что брать на секцию. - Формулировка про частичные отказы для первого этапа секции: «проектирую под частичные отказы: одна из двух записей может не пройти — вопросы консистентности решаю протоколом, а не ретраем». - Backpressure — одно слово, которое поднимает блок деградации (KB §9): «очередь не бесконечная, при перегрузке — отказ на входе, drop или ошибка клиенту, счётчик растёт». - Partial availability на примере ленты: «лучше недоступна лента у 1% пользователей, чем у всех нет счётчиков» — стыкуется с yield/harvest Брюера (материал 26). - «Ты не Шерлок, пока метрики не подтверждают» — на вопрос про эксплуатацию/инциденты; вместе с «перцентили, не средние» закрывает словарь наблюдаемости. - Кейс Twitter про пространство ID — готовый ответ на «как бы вы выбирали ключи партиционирования» (стыкуется с §13.4 KB и Instagram IDs).

3.4 On Designing and Deploying Internet-Scale Services (Hamilton, LISA'07) — чек-лист operations-friendly

Выжимка. Классика эксплуатации от архитектора Windows Live/Exchange (позже AWS): соотношение «систем на администратора» — от 2:1 до 2500:1, и главный фактор — не автопилот, а то, спроектирован ли сервис для автоматизации. Три заповеди: expect failures / keep things simple / automate everything. «80% операционных проблем рождаются в дизайне и разработке». Ключевые правила: design for failure — за 10 000 серверов и 50 000 дисков отказы случаются несколько раз в день, любое требование «человеческого вмешательства» при отказе делает сервис неремонтопригодным; тест на синхронную репликацию и автотейковер — «готова ли ops-команда выключить любой сервер в любой момент без дрейна нагрузки»; crash-only (Fox/Stanford): путь отказа надо дёргать постоянно, поэтому сервис не выключают «по-хорошему» — просто жёстко убивают; моделировать отказы как security threat modeling — «редкие комбинации событий становятся обычными на тысячах машин». Admission control на всех уровнях (не только на входе): лучше не пустить работу в перегруженную подсистему, чем дать всем одинаково плохо; graceful degradation вместо тотального падения (кейс 9/11: новостные сайты легли целиком, хотя могли отдавать подмножество статей). Партиционирование: разбиение fine-grained, не по реальным сущностям (компании «Гугл» не влезет в шард, префикс «P» переполнится) + lookup-таблица в middle-tier. Эксплуатация: soft delete only — ничего не удалять, вести rolling-историю изменений 2+ недели (DELETE без WHERE не спасут ни RAID, ни зеркала); трекать все механизмы отказоустойчивости — ретраи и failover скрывают мелкие отказы, «сервис из 2000 машин незаметно деградировал до 400 за несколько дней»; отладка — дампом памяти из прода, «чем реже трогают прод, тем счастливее клиенты»; «you build it, you manage it» (Amazon); аварийные скрипты проверять в проде «fire drill'ом» — не готов рисковать в дрилле, значит скрипт не готов к аварии. Коммуникации: сообщать клиентам статус и ETA восстановления — удовлетворённость выше, даже у бесплатного сервиса.

Что брать на секцию. - Шесть фактов для блока «эксплуатация» (KB §10): 2500:1; отказы несколько раз в день на 10K серверов; «выключи любой сервер без дрейна» как тест HA; admission control на каждом ярусе; soft delete + история изменений; трекинг FT-механизмов (2000→400). - Связка «80% проблем рождаются в дизайне» — аргумент в ответе «как вы проектируете надёжность»: не пост-фактум мониторингом, а ограничениями в дизайне (single-version software, pod-изоляция, отсутствие SPOF). - «Редкие комбинации отказов становятся обычными» — зрелая реплика в разговоре про multi-ДЦ и отказоустойчивость брифа 08. - Кейс 9/11 и «большая красная кнопка» деградации — конкретика к graceful degradation, стыкуется с Netflix/Brewer (материал 26).

3.5 Dapper (Google, 2010) — распределённая трассировка: как «see the whole request»

Выжимка. Технический отчёт Google про 2+ года продакшена системы трассировки: один universal search запрос обрабатывают тысячи машин, и без сквозного наблюдения «поведение системы неотличимо от шаманизма». Модель: trace tree из span'ов (имя, timestamp, RPC-данные) с tree-структурой вызовов; распространение трассировочных контекстов через общие библиотеки (thread pool, RPC, control flow) — приложение трогать не надо, инструментирование точечное; данные пишутся в локальные файлы, собираются асинхронно — трассировка не на пути запроса. Цена решается сэмплированием: дефолт 1/1024 (до 0.01% для самых горячих сервисов), влияние на латентность неотличимо от нуля при частоте ≤1/16; адаптивное сэмплирование «N трейсов в секунду» для низконагруженных; агрессивное сэмплирование не мешает анализу — «если паттерн важен, он проявится тысячи раз»; >1 TB трейсов в день, хранение 2+ недели, демон <0.3% ядра, сбор <0.01%. Главный побочный эффект: Dapper начал как инструмент, а стал платформой — на его данных построили непредвиденные авторами инструменты (анализ сервисных конфигураций, сетевая отладка, профиль латентностей); наследники — Zipkin, SkyWalking, OpenTelemetry.

Что брать на секцию. - Ответ на «как вы наблюдаете распределённый запрос» (KB §10 говорит «traces: OpenTelemetry, сквозной trace id» — теперь с первоисточником): «сквозной trace id прокидывается через общие библиотеки, спаны собираются в дерево вызова; сэмплируем 1/1024 — на горячих сервисах важный паттерн всё равно проявится тысячи раз; поэтому трассировка стоит ноль на пути запроса». - «Трассировка — платформа, а не инструмент»: по трейсам строят профиль латентностей и ловят конфигурационные деградации — готовый ответ на «что даёт наблюдаемость бизнесу». - Связка с Hodges («it's slow» — самая тяжёлая отладка, Dapper и Zipkin построены ради неё): два источника одним голосом.

4. Второй эшелон (после секций / по остаточному времени)

5. Как использовать

1. Первоисточник для цитирования (§3.1, §3.5) — по одной фразе-маркеру: «как в Dynamo: always-writable корзина, SLA на p99.9, (3,2,2)»; «как в Dapper: трейс — дерево спанов через общие библиотеки, сэмплируем 1/1024».
2. Механика отказов (§3.2) — 30 минут визуализаций перед тренировкой: выборы/термины/кворум должны проговариваться без запинки в блоке «отказоустойчивость» брифа 08.
3. Операционный слой (§3.3–3.4) — словарь и чек-лист для финального этапа секции («эксплуатацию говорим всегда», KB §10): backpressure, partial availability, перцентили, soft delete, трекинг FT-механизмов, «выключи любой сервер без дрейна».
4. Чего в списке нет: разборов под формат интервью и кейсов компаний — за ними в lsd-awesome-scalability.md, lsd-interviewready-resources.md, ../classic-designs.md.

Связанные документы

• ../knowledge-base.md — §5 (репликация), §6 (шардирование), §7 (консистентность/консенсус), §9 (отказоустойчивость), §10 (эксплуатация), §13.4 (ID)
• ../articles/08-fault-tolerance.md, ../articles/09-consistency.md, ../articles/12-operations-observability.md — статьи брифа, куда ложатся темы топ-5
• lsd-interviewready-resources.md — материал 27: The Log и академические первоисточники (компаньон по Papers)
• lsd-awesome-scalability.md — материал 26: прод-кейсы тех же паттернов (Dynamo-механики в бою — Cassandra/DynamoDB-наследники)
• learn-system-design-index.md — индекс подборки (этот материал — №28, Advanced, P3)