title: Конспект материала 29 — awesome-system-design-resources (ashishps1) source: https://github.com/ashishps1/awesome-system-design-resources author: ashishps1 (Ashish Pratap Singh, AlgoMaster.io) — «бесплатные ресурсы для изучения System Design и подготовки к интервью»: ~140 ссылок, 12 тематических разделов + каталог из 45 задач с tiering Easy/Medium/Hard + 6 «must-read» engineering-статей + 10 канонических пейперов; большая часть ссылок — собственный блог автора (algomaster.io / blog.algomaster.io) конспект: подготовлено 2026-09-18, TASK-45.33; README прочитан целиком, все ссылки классифицированы по уникальности относительно 45.12–45.32; топ-5 прочитаны полностью — Top 15 Tradeoffs (AlgoMaster), Discord trillions of messages, Slack Real-time Messaging, Kleppmann «How to do distributed locking», Stripe «Payments APIs: the first 10 years» (Discord и Stripe отдают сайт только после JS — читал через r.jina.ai / web.archive, текст совпадает с оригиналом) статус: P3-источник «после секций»; единственное исключение — §3.1 (трейдоффы): это словарь развилок, дешёвый 15-минутный прогон перед любым слотом (все 15 пар — уже пройденные темы, здесь они собраны в единый чек-лист). Остальное — новые кейсы на глубину: хранилище лент (Discord), real-time доставка (Slack), локи (Kleppmann), API-эволюция (Stripe)

Материал 29: awesome-system-design-resources (ashishps1) — индекс и топ-5

Отличие от уже разобранных подборок: это не кейсы компаний (45.30), не «внутренности» по инженерным блогам (45.31) и не канон распределённых систем (45.32), а «учебник-минимум + задачник + витрина свежих инженерных статей». Ядро — короткие концепт-статьи самого автора (AlgoMaster), каталог классических задач с tiering по сложности и 6 engineering-постов 2020–2023. В отличие от karanpratapsingh (45.13) глубина концептов меньше, но зато есть два уникальных слоя, которых не было ни в одном источнике: систематический свод трейдоффов (15 пар + по статье на каждую пару) и ранжированный задачник из 45 задач. Слабости: самопиар (большая часть ссылок ведёт на AlgoMaster-блог с воронкой подписки, часть контента платная), задачи закрыты видеоразборами (пассивное смотрение), часть концептов дублирует учебники, опечатка в README (ссылка «Design Autocomplete for Search Engines» ведёт на разбор Instagram — рассинхрон текста и URL), один канон-LSM и Dynamo — это дубли уже пройденного.

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

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

1. Прямая релевантность брифу (крупноблочная схема Instagram/Twitter + отказоустойчивость) и связка с уже пройденным: 45.30 дал компоненты ленты (ID, соцграф, кэш, деградация), 45.31 — «внутренности» под капотом. Здесь берём следующий слой цельного кейса: хранилище сообщений ленты целиком (Discord), real-time доставку «сервер→клиент» (Slack — в связке с WebSocket-профилем пользователя), корректность распределённого доступа (локи Kleppmann), эволюцию API (Stripe — финтек-домен пользователя), и сквозной инструмент (трейдоффы).
2. Не дублировать пройденное: кэш-кейсы закрыты (45.16/45.30), консенсус — Raft-визуализации (45.32), LSM/Dynamo/Bigtable — 45.30/45.31/45.32. LSM не берём в топ-5, хотя он в списке: Discord даёт его же на живом кейсе (compaction backlog как причина тоила) — красивее и свежее, чем пейпер 1996 года.
3. Доступность и полнота: все топ-5 прочитаны целиком (Discord/Stripe — через r.jina.ai и web.archive версии, совпадают с оригиналом). Видеоразборы из «проблем» сознательно исключены из топ-5: смотреть час видео на слот неэффективно, конспекты письменных источников перечитываются за 20 минут.
4. «Одна фраза на секцию»: каждый топ-материал даёт маркер, который поднимает ответ на класс глубины выше типового.

3. Топ-5

3.1 Top-15 Tradeoffs — словарь развилок (сквозной инструмент)

Выжимка. «Rule No.1 of System Design: it's all about tradeoffs» — статья-сводка 15 пар, на каждую: определение + реальный пример. Пары: 1) scalability vs performance (больше машин = сложнее координация и задержка); 2) vertical vs horizontal (простота+SPOF против «бесконечного» масштаба); 3) latency vs throughput (игры vs аналитика); 4) SQL vs NoSQL (жёсткие транзакции и сложные запросы против гибкости и масштаба — банки vs Netflix); 5) consistency vs availability (CAP: заказ на Amazon → свежий сток; мессенджер → жить всегда); 6) strong vs eventual (перевод → балансы сразу; Instagram → пост появится в лентах «скоро»); 7) read-through vs write-through cache (частые чтения — тяни в кэш при miss; бронирование билетов — пиши сразу в оба); 8) batch vs stream (выписки раз в день vs фрод-детекция в реальном времени); 9) sync vs async (оплата — ждём подтверждения; загрузка фото — фон); 10) stateful vs stateless (корзина магазина — память сессии; REST — каждый запрос самодостаточен); 11) long polling vs WebSockets (уведомления — держим запрос открытым; мультиплеер — постоянно открытый канал); 12) нормализация vs денормализация (низкая избыточность против скорости чтения — блог хранит комментарии с постом); 13) monolith vs microservices (простота старта против независимого масштабирования и координации); 14) REST vs GraphQL (простота, кэшируемость против одного запроса «что нужно»); 15) TCP vs UDP (гарантия доставки/порядка против низкой задержки — email vs стриминг/гейминг).

Что брать на секцию. - Готовый рефрен на любую развилку схемы: «вот пара, что выбрали и чем платим». Интервьюер почти всегда спрашивает «а почему так, а не иначе» — 15 заготовленных пар с примерами закрывают 90 % таких вопросов без импровизации. - Пары с числами/конкретикой лучше всего: «банки — SQL: транзакции точнее гибкости», «лента — eventual: пост появляется с задержкой и это ок» (прямо наш бриф!), «бронирование — write-through (иначе overbooking)», «CS:GO — UDP, Skype/email — TCP». - Не учить заново — все темы уже в KB/учебниках; это именно список «какие развилки обязан проговорить». Прогон = 15 минут, по одной строке на пару. - Стыкуется с методичкой: трейдофф — последний шаг любого блока ответа (назвал решение → назвал трейдофф → назвал пример).

3.2 Discord — хранилище сообщений ленты (триллионы сообщений)

Выжимка. Эволюция сообщений Discord: MongoDB → Cassandra (2017, 12 нод) → 177 нод в начале 2022 («high-toil»: on-call пейджится, латентность непредсказуема) → ScyllaDB (май 2022). Схема: PRIMARY KEY ((channel_id, bucket), message_id) — партиция = канал × bucket (статическое временное окно), сообщения сортируются по message_id (Snowflake ID — хронологически сортируемый, как у Twitter/Instagram). Болезни Cassandra: hot partition (канал с большой аудиторией: @everyone → шквал чтений в одну партицию → каскадная латентность всей ноды → страдают все запросы, т.к. чтения идут с quorum-консистентностью); чтения дороже записей (memtable + несколько SSTables против append в commit log); compaction backlog (операция «gossip dance»: вывод ноды из ротации, чтобы она доуплотнилась без трафика); JVM GC-паузы → латентные спайки (ScyllaDB на C++ без GC — ключевая мотивация миграции). Защита БД: data services на Rust между API-монолитом и кластерами — по одному gRPC-эндпоинту на запрос, без бизнес-логики; главная фича — request coalescing (несколько запросов на одну строку → один поход в БД, остальные подписываются на таск) + consistent-hash routing по channel_id (все запросы канала — в один инстанс сервиса → эффективнее коалисценция). Миграция: 3.2 млн сообщений/с через переписанный на Rust мигратор (токен-рэнджи БД + SQLite чекпоинты), застряли на 99.9999 % из-за громадных диапазонов томбстоунов в Cassandra (не скомпактились) — скомпактили диапазон, миграция за секунды; валидация — теневые чтения (малый % чтений шёл в обе БД, результаты сравнивались). Итог: 177 Cassandra-нод (4TB каждая) → 72 ScyllaDB-ноды (9TB); p99 чтения истории 40–125 мс → 15 мс; insert 5–70 мс → 5 мс; World Cup-финал выдержал без взволнованного дашборда.

Что брать на секцию. - Схема хранения ленты целиком — не было ни в одном источнике: партиционирование «channel × time-bucket + сортируемый ID» — готовая модель для блока «где храним посты/сообщения» (стыкуется с Instagram IDs из 45.30). - Hot partition — маркер-страшилка, которой отвечают на «а что ломается в шардированной ленте»: «один вирусный канал роняет латентность всей БД, потому что quorum-чтения в эту партицию забивают ноду». Защита — coalescing + consistent-hash routing (приём уровня «я думал о защите БД от пиков», редко звучит у кандидатов; то же семейство, что single-flight). - LSM на живом кейсе: пейпер 45.31 (3.4) называет причины — здесь видно следствие: compaction backlog = тоил on-call + «gossip dance». Фраза «write-heavy хранение ленты — LSM-семейство, и платишь compaction-операциями» связывает теорию с реальностью. - Снежинка: Snowflake-IDs с хронологической сортировкой вторично подтверждены (45.30 говорил то же про Instagram) — «ID = время, сортировка ленты бесплатна». - Миграция без даунтайма (dual-write + shadow reads + быстрый мигратор) — готовый ответ на «как переезжать с БД на БД» (вопрос-бонус в эксплуатации).

3.3 Slack — real-time доставка сообщений

Выжимка. Slack отправляет миллионы сообщений в день по миллионам каналов, доставка в мире — 500 мс. Ядро — четыре Java-сервиса: Channel Servers (CS) — stateful, in-memory, держат историю каналов; каждый CS мапится на подмножество каналов consistent hashing'ом (в пике ~16 млн «каналов» на хост; «канал» — абстрактный ID: user, team, file, huddle…). CHARMs — управляют consistent-hash-кольцом, заменяют сдохший CS за < 20 секунд (регистрация/обнаружение — Consul). Gateway Servers (GS) — stateful, держат юзеров и WebSocket-подписки; единственный сервис, развёрнутый по нескольким регионам (клиент цепляется к ближайшему; draining при падении региона бесшовно переводит пользователей в соседний). Admin Servers (AS) — stateless, интерфейс между Webapp-бэкендом и CS. Presence Servers (PS) — кто онлайн (зелёные точки); юзеры хэшируются на PS, клиент подписан на presence только видимых на экране юзеров. Путь сообщения: клиент → Webapp API → AS → CS канала (по кольцу) → всем GS мира, подписанным на канал → каждому клиенту с open-WebSocket на этот канал. Особая категория — transient events (не персистятся: «печатает…») — идут тем же путём без БД. Перекрёстные наблюдения: спайки трафика ровно «в час» — напоминания/запланированные сообщения; разные регионы имеют разный prime-time (multiplicative factor бродкаста отличается).

Что брать на секцию. - Эталон real-time-слоя: кандидаты обычно заканчивают на «WebSocket-серверы»; здесь — полная связка: stateful шлюзы с consistent-hash, подписки каналов, мульти-регион с draining, доставка 500 мс как измеримая цель. Готово для блока «доставка в реальном времени» в схеме чата/ленты. - Williams: presence «только видимые» — приём экономии ресурсов (не подписывать всех на всех), аналогично «лента показывает подмножество». - Прямая стыковка с профилем: Samokat Go + Kafka → WebSocket — «я строил доставку событий по WebSocket в прод; вот именно такие проблемы (подписки, регионы, reconnect)». В cover letter Runware WebSocket уже упомянут — здесь материалы, чтобы отвечать вглубь. - Transient events — ответ на «как сделать “печатает…” без записи в БД» (часто спрашивают в мессенджерах); «напоминания в топ часа — отсюда спайки» — хорошая деталь «я думал о паттернах нагрузки». - Consistent hashing снова третьим источником (CS-маппинг, data services Discord, TAO 45.30) — паттерн, который обязан называться с ходу.

3.4 Kleppmann — distributed locking (канон по локам)

Выжимка. Классика (автор DDIA), разбор Redlock. Две причины для лока: efficiency (сэкономить повторную работу — «заплатил 5 центов AWS лишний раз» — «no big deal») и correctness (не дать двум нодам испортить состояние — «кто-то получит двойную дозу лекарства»). Для efficiency достаточно одного Redis с async-репликой (потеря лока при краше — ок, и всем очевидно, что лок приблизительный). Для correctness Redlock не годится. Ключевой слом: даже идеальный лок-сервис не спасает код вида acquire → read → modify → write → release: GC-pause дольше lease-таймаута (клиент «заснул», лок истёк, другой клиент взял лок и записал, первый «проснулся» и перезаписал — испорченные данные; это был реальный баг HBase). Фикс — fencing token: монотонно растущее число от лок-сервиса (клиент 1 получил 33; после его паузы клиент 2 взял лок и токен 34; хранилище помнит «уже обработал запись с токеном 34» и отклоняет запись с токеном 33). Требует активной роли хранилища (проверять токены), но просто; в ZooKeeper fencing-токен = zxid/версия znode. Redlock fencing-токены генерировать не умеет (а для монотонного счётчика нужен консенсус) — этого одного достаточно, чтобы не использовать его там, где важна корректность. Модель: asynchronous + unreliable failure detectors; таймауты — лишь догадка о падении.

Что брать на секцию. - Готовый ответ на «как сделать распределённый лок» выше типового «Redis SETNX»: «если лок для efficiency — хватит одного Redis; если для correctness — нужны fencing-токены и проверка в хранилище, а не просто TTL» (пользователю знакомо — внутренний RPC-протокол/платежи: «двойной списания»). - Fencing-токен — редкий для кандидатов приём: «ясно, что лок нужен, но мало кто защищается от повторной записи после GC-pause». Маркер из DDIA-мира — усиливает позицию «я читал первоисточники». - Сценарий GC-pause: в ответах про «сервис завис» (бриф 09) — то же семейство, что retry storm; одна фраза «pause → lease истёк → старый воркер пишет без лока → fencing-токен отклоняет» связывает отказоустойчивость и корректность. - Спутник: Redlock-критика — красиво звучит как осознанный выбор, а не «слушал, что Redis умеет локи».

3.5 Stripe — эволюция платёжного API (10 лет)

Выжимка. Как абстракции API дрейфуют с ростом домена. 2011: Charges + Tokens — «семь строк кода» для карт: Stripe.js собирает карту → Token (секретные реквизиты у Stripe, без PCI у мерчанта) → сервер синхронно создаёт Charge. Фундамент оказался заточен под самый простой платёжный метод (карты: мгновенная финализация, нет действия клиента). 2015: ACH (финализация через дни) + Bitcoin (клиент сам инициирует, ~час до финализации) → пришлось добавлять pending-состояние в Charge, а для Bitcoin — отдельный BitcoinReceiver (второй state machine!). 2015–2017: Sources API — единый клиентский ресурс на все методы, но серверная пара «Source + Charge» = две state machine с разными состояниями и путями; iDEAL-кейс — «клиент заплатил в банке, браузер потерял коннект, server никогда не создал Charge → возврат денег» (потеря конверсии); вебхуки charge.succeeded — в критическом пути сбора денег. 2018: PaymentIntents + PaymentMethods (комната Lynx, 5 человек, 3 месяца, закрытые ноутбуки, «цвета и фигуры» на доске вместо имён, гипотетические интеграционные гайды на каждый метод — включая «отправка денег голубем»). PaymentMethod = «как» (статика: способ и реквизиты), PaymentIntent = «что» (stateful: сумма, попытки); единый state machine: requires_payment_method → requires_confirmation → requires_action → processing → succeeded / нет failed — неудачная попытка возвращает в requires_payment_method (клиент повторяет с другим методом тем же объектом); единственный обязательный вебхук payment_intent.succeeded — не в критическом пути. Роллаут занял ~2 года: нельзя ломать интеграции — layered migration: PaymentIntent создаёт Charge под каждую попытку, аналитика/отчётность продолжают работать на старом ресурсе; Charge разросся с 11 до 36 свойств (5 → 14 параметров создания) — отсюда polymorphic payment_method_details (типизированный хэш, чтобы верхний уровень ресурса не распухал). Процессные уроки: «запирали в комнате и принимали решения быстро, даже если потом отменяли».

Что брать на секцию. - API-дизайн как история: «абстракции под первый use case не переживают второй домен — перепроектируй под один state machine, а не статус за статусом» — сильный ответ на «спроектируй API» (бриф 01) и на «как мигрировать публичный API без ломки клиентов» (layered migration). - State machine как инструмент: «у платёжной сущности один state machine, нет failed — неудача возвращает в начало, клиент пробует другой метод»: готовый паттерн для денежных/заказных сущностей (значает «я проектировал деньги» — профиль: финансы в Balance Platform/Raiffeisen). - Не-критичный вебхук — та же идея, что (3.2) outbox: «оповещение о результате не блокирует основной путь» — связка с 45.31 (3.2). - Card ≠ норма: «методы со сдвинутой финализацией (ACH дни, Bitcoin часы) ломают синхронную модель» — хорошо для вопросов про деньги/асинхронность. - Не для схемы Instagram/Twitter — но для пользователя это «свой домен»: эпизод про костыли статусами — почти дословно про «статусы и стейты в платежах», о которых он писал в applications.

4. Второй эшелон

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

1. Перед любым слотом — только §3.1 (трейдоффы): 15 пар × одна строка = 15-минутный прогон-словарь. Не открывать новое: остальное — глубина для следующих секций (P3).
2. Связка компонентов ленты теперь полная: ID (Snowflake — 45.30/3.2) → хранилище сообщений (Discord 3.2) → доставка real-time (Slack 3.3) → кэш лент (TAO 45.30, CacheFront 45.31). Вопросы «а как лента хранит сообщения» и «как доставляется» больше не открытые.
3. Словарь развилок из §3.1 — приём «назвал трейдофф + пример» расставляется в любом блоке ответа (методичка: решение → трейдофф → пример).
4. Локи (3.4) и API (3.5) — «свои» темы пользователя: деньги и корректность; маркеры fencing-токен и «один state machine вместо статусов» звучат экспертно именно в финтех-контексте.
5. Чего в репо нет: BOE-чисел (KB §1), RU-моков (45.26/45.27), стратегии интервью (методичка), глубины по хранилищам (DDIA 45.39). Задачник (Easy→Hard) пригодится после секций как каталог тренировок; письменные разборы scheduler/notification — для сверки в ../classic-designs.md.

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

• ../knowledge-base.md — §3 (сеть/доставка), §4 (кэш), §5–§6 (хранилища, шардирование/LSM), §7 (согласованность/локи), §8 (очереди/потоки), §9 (отказоустойчивость), §10 (эксплуатация), §13 (прикладные компоненты — локи)
• ../classic-designs.md — §2 (лента: fan-out), §7 (эталонные схемы); письменные разборы ashishps1 — на сверку
• lsd-awesome-scalability.md — материал 26: компоненты ленты (ID/соцграф/кэш); Discord 3.2 и Slack 3.3 — их «хранилище и доставка»
• lsd-interviewready-resources.md — материал 27: The Log (↔ Kafka-paper), LSM (↔ ScyllaDB в 3.2), Transactional Outbox (↔ «не-критичный вебхук» в 3.5)
• lsd-awesome-distributed-systems.md — материал 28: Raft (вход в консенсус; Paxos — первоисточник), Dynamo (канон, в курсе)
• learn-system-design-index.md — индекс подборки (этот материал — №29, Advanced, P3)