title: Конспект материала 15 — Architecture Notes (architecturenotes.co) source: https://architecturenotes.co/ author: Mahdi Yusuf (Substack) конспект: подготовлено 2026-09-17, TASK-45.19; архив выгружен целиком через API Substack — 20 постов за 2022-05..2025-06 (12 бесплатных, 8 платных); прочитаны полные тексты всех топ-5 и 12 Factor; выжимки по фактам из текстов, не по заголовкам статус: P3-источник к слотам 21–22.09. Сайт мал и уже не активен (последняя содержательная статья — январь 2023, дальше анонс переезда и эссе про AI), но бесплатное «Explained»-ядро 2022 года — это готовые deep-dive карточки по Redis, шардированию, индексам, LB и гранулярности сервисов: по одному на тему брифа. Подписка не нужна

Материал 15: Architecture Notes — индекс и топ-5

Architecture Notes — персональный блог Mahdi Yusuf: длинные эссе «Explained» по архитектуре реальных компонентов (Redis, RDBMS, LB, шардирование) с инфографиками. Это не учебник (роль учебников у нас — SDP, karanpratapsingh, DDIA) и не банк кейсов (роль живых кейсов — блог ByteByteGo, материал 12). Ценность другая: это готовые «карточки глубины» — по одному эссе на тему брифа, каждое читается за 15–25 минут и даёт слой «как это устроено внутри», которым отвечают на уточняющие вопросы интервьюера (устройство Redis, цена 2PC, изоляция в RDBMS).

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

Публикация фактически заморожена: содержательный поток — май 2022 – январь 2023, дальше анонс переезда на Substack (2024) и одно эссе про AI-код (2025). Это не минус для подготовки: формат «компонент объяснён целиком» устаревает медленно.

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

1. Прямая релевантность секции: крупноблочная схема сервиса класса инстаграм/твиттер + отказоустойчивость; темы брифа — хранилища, кэш, шардирование, масштабирование, уровень архитектуры.
2. Доступность: все топ-5 — бесплатные, прочитаны полностью.
3. Не дублировать уже покрытое: кэш-паттерны (cache-aside, инвалидация, herd) у нас уже закрыты кейсом Facebook/Memcached (материал 12 §3.3), поэтому Redis берём не как «ещё один кэш-кейс», а как устройство Redis-топологий и персистентности — этого нигде больше нет.

3. Топ-5 статей

3.1 Redis Explained (2022-08-11) — карточка глубины по кэшу

Выжимка. Redis = «REmote DIctionary Service», in-memory сервер структур данных, а не просто KV: структуры с нуля вместо сортировки строк; изначально сравнивали с Memcached (тот — только LRU, без типов данных и персистентности; зато многопоточный, Redis — однопоточный), но Redis вырос в полноценное хранилище для отдельных сценариев. Четыре топологии, по нарастанию сложности: Single Instance (просто; падение инстанса = деградация системы; при деплое на той же машине — быстрый выигрыш) → HA (main + реплики: у каждой репликации replication ID + offset; разъехались на несколько команд — досылаем недостающее, неизвестен ID/offset — полный sync через RDB-снапшот + буфер промежуточных апдейтов) → Sentinel (кластер наблюдателей: monitoring / notification / failover / service discovery — клиент спрашивает у сентинелов, кто сейчас main; отказ main фиксируется кворумом; рекомендация автора — сентинел рядом с каждым app-сервером, минимум 3 ноды с кворумом 2; при нетворк-сплите записи ушедшей в меньшинство старой main теряются) → Cluster (горизонтальное масштабирование: 16384 hashslot'а; ключ → hash → слот → шард; решениешардинг = перенос слотов между шардами без даунтайма, а не перенос ключей; здоровье кластера — gossiping; риск split-brain при неверном кворуме; правило: нечётное число primary + по 2 реплики). Вся репликация асинхронна — durability-гарантий нет; смягчение: main перестаёт принимать записи, если хотя бы одна реплика не подтвердила. Персистентность: RDB (point-in-time снапшоты — потери между снапшотами, быстрый загруз) / AOF (append-only лог команд + fsync — долговечнее, но не компактен; при рестарте с обоими включёнными побеждает AOF) / никакой (быстрее всего). Самое элегантное: снапшоты через fork + copy-on-write — ребёнок шарит страницы памяти, ядро копирует страницу только при записи, гигабайты снапшотятся быстро и с минимальной доплатой памяти. Философия автора: «Redis быстр, и все гарантии консистентности уступают скорости».

Что брать на секцию. - Готовый ответ на «какой кэш и как деплоите»: single → HA-реплики → Sentinel → Cluster — прогрессия по мере роста, называть с трейдоффами. Это одновременно ответ на «что будет, если кэш умрёт» (KB §4): кэш-слой сам спроектирован с фейловером. - Hashslot'ы (16K) — лучший короткий ответ на «как решардингить без остановки»: ключи маппятся в слоты, между шардами двигаем слоты, а не ключи. Связка с consistent hashing (KB §6) — два конкурирующих механизма решения той же задачи. - Quorum на примере сентинелов — конкретика для KB §7/§9: 3 ноды / кворум 2, split-brain, потери записей меньшинства. «А что с записями на отрезанной main?» — частый добивающий вопрос. - fork + COW — аргумент уровня «понимаю внутренности»: как однопоточный сервис делает снапшот гигабайт памяти без остановки мира. - Честная фраза про трейдофф: «кэш спроектирован на скорость, async-репликация = возможная потеря последних записей; для ленты приемлемо, для денег — нет».

3.2 Database Sharding Explained (2022-12-12) — шардирование с приоритетом «сначала простое»

Выжимка. Тон post'а — антиэнтузиазм: «у меня были таблицы в миллиарды строк без шардирования — паттерн доступа не требовал»; «если проблема решается машиной побольше, в 9 случаях из 10 это и есть правильный ответ». Чек-лист альтернатив ДО шардирования: do nothing (нет узкого места — не трогаем) → vertical scaling (RAM/CPU/диск без редизайна) → replication (масштабирует чтение: больше копий + балансировка/геораспределение; WAL — durable-лог, из которого PostgreSQL/MySQL реплицируют и восстанавливаются; запись хуже — её надо довести до каждой ноды) → специализированные хранилища (поиск → Elasticsearch, блобы → S3 вместо реляционного хранилища). Если всё же шардируем — термины: shard key (часть первичного ключа, решает распределение; данные с одним ключом живут на одной ноде), logical shard (группа данных с одним ключом, атомарна — на одну ноду) vs physical shard (нода с несколькими логическими). Три стратегии: key-based (детерминированный хеш: равномерно, адресация на лету, но решардинг труден), range-based (диапазоны + lookup-таблица; ключ с высокой кардинальностью и равномерным распределением, иначе hotspot — узел упёрся в ресурс; авторский пример celebrity-hotspot'а — «Bieber Bug»), relationship-based (связанные данные на одном физическом шарде: пользователь + посты + комментарии — сильнее консистентность внутри, меньше cross-shard запросов; пример — Instagram). Кросс-шард: рано или поздно любой живой сервис упрётся в global transaction; 2PC — лидер пишет durable-запись транзакции, участники фиксируют готовность, лидер коммитит после всех подтверждений; цена — write amplification (минимум одна запись на участника + запись транзакции) и read amplification (каждое чтение, даже нетранзакционное, обязан фильтровать недоведённые состояния); чем дольше открыта транзакция, тем больше contention и отказов.

Что брать на секцию. - Секвенция «do nothing → вертикаль → реплики → спец-хранилища → шардирование» — идеальный ответ на «когда будете шардировать ленту?»: сначала показать зрелость, потом схему. Совпадает с KB §6. - Выбор стратегии под наш кейс: лента/чат — relationship-based по user_id (все данные пользователя на одном шарде: локальность + консистентность), селебрити — hotspot «Bieber Bug», снимается pull-стратегией (KB §1, classic-designs §2). - Кардинальность ключа шардирования — готовый уточняющий вопрос интервьюеру/себе: «какое распределение значений ключа? проверяли на реальных данных?» - Цена 2PC (write+read amplification, «фильтровать недоведённое состояние в каждом чтении») — конкретика для брифа 09/KB §7: почему избегаем кросс-шард транзакций и строим модель без них (данные пользователя на одном шарде — relationship-based это и покупает).

3.3 Relational Databases Explained (2022-06-27) — индексы и транзакции изнутри

Выжимка. Две темы, которые автор считает минимальным набором про RDBMS. Индексы: структура данных, ускоряющая поиск ценой хранения и замедления записи; leaf-ноды индекса — компактное представление колонки → легко кэшируется + указатель на место строки на диске; порядок листьев держит двусвязный список (вставка/удаление — правка указателей, чтение в обе стороны); наверху — B+tree: промежуточные узлы не хранят данные (лучше кэшируется сама структура), листья связаны → index scan одним линейным проходом; логарифмическая магия: при ветвлении M=5 высота 3 покрывает 125 листьев, высота 9 — уже 1.95 млн (M^N), поэтому поиск почти мгновенен при гигантских данных. Транзакции: ACID по определениям; между BEGIN и COMMIT — COMMIT (персистим) или ROLLBACK (откатываем). Три read phenomena: dirty read (видим незакоммиченное), non-repeatable read (два чтения в транзакции дают разные значения одной строки — строку закоммитили и изменили между чтениями), phantom read (агрегат: между чтениями появились/исчезли строки диапазона). Замки по уровням: сериализация БД → таблица → строка → range locks (блокируют вставку/изменение в диапазоне — лечат фантомы). Четыре уровня изоляции SQL-стандарта: READ UNCOMMITTED (dirty-чтения — «кошмар»), READ COMMITTED (каждое чтение — свой снапшот закоммиченного; возможны фантомы), REPEATABLE READ (снапшот от первого чтения на всю транзакцию; защищает от dirty и non-repeatable; транзакции держать короткими), SERIALIZABLE (запросы по одному; нужны ретраи; на нём строятся новые распределённые БД — пример CockroachDB). Важная оговорка автора: определения уровней в конкретных СУБД различаются — читайте документацию своей продакшен-БД.

Что брать на секцию. - B+tree за 3 фразы (данные только в листьях, листья связаны, логарифмический рост) — ответ на «почему индекс ускоряет чтение и что платим?» — бриф 04/KB §3. - Матрица «phenomenon × isolation level» — самая спрашиваемая часть брифа 09 после CAP: уметь назвать все три явления и какой уровень от чего защищает. Про деньги (платежи) — SERIALIZABLE/REPEATABLE READ + короткие транзакции; про ленты — READ COMMITTED достаточно. - Оговорка «в разных СУБД уровни реализованы по-разному (например, Postgres REPEATABLE READ — это снапшот-изоляция)» — звучит как зрелость; для глубины — DDIA гл. 8 (KB §12). - Range locks — мостик к «как БД защищает агрегаты»: блокировка диапазона запрещает вставки внутрь.

3.4 Load Balancers (2022-11-02) — карточка «первый горизонтальный шаг»

Выжимка. LB появляется, когда один сервер не тянет: роутит трафик по пулу серверов; с одним сервером сайт лежит при его падении, минимум два. Алгоритмы распределения: Round Robin (по очереди), IP Hashing (клиент приколочен к серверу — для session persistence), Least load (наименее загруженному по числу соединений). Дивиденды: меньше даунтайма, масштабируемость, redundancy, flexibility, efficiency. Уровни: L4 действует на транспортном/сетевом (IP, TCP), L7 видит прикладной слой (HTTP) — умеет, например, отводить трафик на новый сервис; авторский любимый пример — Strangler Pattern: фасад перед старой системой, за фасадом постепенно вырастают замены, вызовы переносятся на новые сервисы, старые «задушиваются». Failover: LB знает здоровье серверов и быстро выводит плохие из пула, без дырок в сервисе.

Что брать на секцию. - Минимум для брифа 03: LB в схеме ленты — L4/L7, алгоритмы и когда какой (IP hash — если сессии; least connections — при неравномерных запросах; round robin — базовый). - Strangler — готовый ответ на «как мигрируете монолит на сервисы без остановки»: фасад на L7, переносим по фичам. Отлично стыкуется со статьёй про монолит/микросервисы (§3.5). - Health checks + автоисключение нод — первый кирпич блока отказоустойчивости (KB §9): «что будет при падении app-сервера?» — «LB выведет его из пула».

3.5 Monoliths, Service Architecture, and Microservices (2022-08-27) — гранулярность: короткая, но стратегическая

Выжимка. Три уровня гранулярности с честными плюсами/минусами. Монолит: всё в одном юните; проще и быстрее в начале, производителен, меньше кросс-функциональных проблем; минус — с ростом сложности падает ловкость изменений. Вердикт автора: «большинство систем должно остаться монолитом — respect the monolith». SOA: слабо связанные полноценные юниты, часто с общей БД; лучше границы и тестируемость, команды параллелятся; минус — время отклика системы, координация и планирование заранее. Микросервисы: ещё мельче — одна ответственность + своя граница данных; проще разрабатывать/тестировать сервис, команды подвижнее; минус — вся сложность распределённых систем, деплой и эксплуатация многих юнитов; таких систем с соответствующими проблемами немного. Стратегическая мораль: заранее не знаешь, что станет самым горячим местом; миграции случаются больше одного раза — или ни разу.

Что брать на секцию. - На старте кейса (бриф 11) — оправдать уровень гранулярности: «начали бы с модульного монолита, выделили бы fan-out/медиа/чат по мере роста» — это трейдофф-мышление, которое ценится выше «нарисуем 20 микросервисов». - Границы: SOA = общая БД, микросервисы = данные на сервис — распространённый вопрос-ловушка «можно ли микросервисам ходить в чужую БД?» - Связка со strangler (§3.4): миграция монолита — не событие, а процесс; фраза «миграции случаются больше одного раза или ни разу» — хорошая финальная реплика про эволюцию архитектуры.

4. Второй эшелон (бесплатные, по темам)

5. Платная серия (подписка не обязательна)

Все платные темы перекрываются нашими бесплатными материалами; таблица — на случай, если подписка уже есть.

6. Как использовать перед слотами

1. Карточки глубины (§3.1–3.4). По 20–30 минут: Redis, шардирование, RDBMS, LB — на каждый уметь своими словами выжимку «что брать на секцию». Это слой ответов на уточняющие вопросы, которых нет в учебниках уровня Alex Xu.
2. Три готовых реплики-маркера: «решардинг без даунтайма — двигаем hashslot'ы, а не ключи» (Redis Cluster), «прежде чем шардировать: вертикаль → реплики → спец-хранилища» (§3.2), «миграции случаются больше одного раза или ни разу» (§3.5).
3. §3.5 + strangler (§3.4) — заготовка начала кейса (бриф 11): уровень гранулярности и план эволюции архитектуры вместо «микросервисы сразу».
4. Чего на сайте нет и куда идти: сквозной фреймворк и тайминг — ../methodology.md §2; банк реальных кейсов с цифрами — lsd-bytebytego-blog.md (материал 12); глубина по хранению — DDIA-карта (KB §12); эталонные разборы под наш тайминг — ../classic-designs.md.

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

• ../knowledge-base.md — §3 (классы хранилищ), §4 (кэш), §5 (репликация), §6 (шардирование), §7 (консистентность), §9 (отказоустойчивость)
• ../brief.md — разделы 03 (масштабирование), 04 (модели данных), 05 (репликация/шардирование), 06 (кэш), 09 (согласованность), 11 (эталонные архитектуры)
• lsd-bytebytego-blog.md — материал 12: банк кейсов (Facebook/Memcached, Instagram) — парный к этому по кэшу
• learn-system-design-index.md — индекс подборки (этот материал — №15, P3)