---
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. Как устроен источник

| Формат | Что это | Доля | Ценность для нас |
|---|---|---|---|
| **Серия «Explained»** | Длинные технические эссе по одному компоненту: Redis, реляционные БД, шардирование, LB, шифрование, виртуализация. Инфографика + разбор внутренностей и трейдоффов | ~50% постов | **Ядро**: карточки глубины по темам брифа |
| **Arc Notes / короткие заметки** | Интервью (Datasette/Simon Willison), анонсы CTF, переезд на Substack | ~15% | Пропускаем |
| **Платная серия** | Fallacies of Distributed Systems, Latency, Quorums, Circuit Breakers, Locking and Contention, Virtualization, Types of Memory, Technical Debt | 8 из 20 постов | Темы перекрыты нашими бесплатными материалами (§5) — подписка не нужна |

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

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

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

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

| # | Статья | Дата | Тема | Бриф / KB |
|---|---|---|---|---|
| 1 | [Redis Explained](https://architecturenotes.co/redis) | 2022-08-11 | кэш: топологии, персистентность | бриф 06 / KB §4–§7, §9 |
| 2 | [Database Sharding Explained](https://architecturenotes.co/database-sharding-explained) | 2022-12-12 | шардирование: когда и как | бриф 05 / KB §6–§7 |
| 3 | [Relational Databases Explained](https://architecturenotes.co/things-you-should-know-about-databases) | 2022-06-27 | хранилища: индексы и транзакции | бриф 04, 09 / KB §3, §7 |
| 4 | [Load Balancers](https://architecturenotes.co/load-balancers) | 2022-11-02 | масштабирование: LB, L4/L7, strangler | бриф 03 / KB §3, §9 |
| 5 | [Monoliths, Service Architecture, and Microservices](https://architecturenotes.co/granularity-of-systems) | 2022-08-27 | гранулярность сервисов | бриф 11 / KB §14 |

### 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. Второй эшелон (бесплатные, по темам)

| Пост | Дата | Тема | Зачем |
|---|---|---|---|
| [12 Factor App Revisited](https://architecturenotes.co/12-factor-app-revisited) | 2022-10-06 | эксплуатация (бриф 12) | Прогон 12 факторов глазами 2022: stateless-процессы и состояние в backing services (основа горизонтального масштабирования — бриф 03), разделение build/release/run (безопасный rollback), конфиг в окружении → Vault. Читать по диагонали, брать факторы processes и build-release-run |
| [Types of Encryption](https://architecturenotes.co/types-of-encryption) | 2022-08-30 | безопасность | Симметричное/асимметричное/хеши; в бриф не входит — только если интервьюер сам спросит про TLS/хранение паролей |
| [Arc Note: Datasette — Simon Willison](https://architecturenotes.co/datasette-simon-willison) | 2022-05-27 | интервью | Разговор с создателем Datasette, соавтором Django; для секции не нужно |
| [Capture the Flag](https://architecturenotes.co/capture-the-flag) | 2022-12-30 | анонс CTF | Пропустить |

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

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

| Пост (платно) | Тема | Чем закрыто бесплатно у нас |
|---|---|---|
| Fallacies of Distributed Systems (2022-06-04) | 8 заблуждений распределённых систем | Классика, пересказана в KB §9 и DDIA-карте (KB §12, гл. 9); список fallacies легко нагуглить |
| Latency (2022-09-01) | латентность по уровням памяти/сети | `lsd-interactive-latency.md` (45.25) + KB §1 |
| Quorums (2022-10-01) | кворумы и консенсус | KB §5/§7 + DDIA гл. 8–9; плюс кворум сентинелов разобран в §3.1 этого конспекта |
| Circuit Breakers (2022-12-20) | предохранители | KB §9 + статья 08 (бриф 08); паттерн в свободном доступе описан во множестве источников |
| Locking and Contention (2023-01-10) | блокировки | База покрыта §3.3 этого конспекта; глубина — DDIA гл. 8 |
| Virtualization Explained (2022-11-13) | виртуализация/контейнеры | Вне брифа; IaC/инфраструктура в нашем профиле закрыта другим опытом |
| Types of Memory (2022-09-03) | типы памяти | KB §1 (числа латентностей) достаточно |
| Technical Debt (2023-01-26) | техдолг | Не для секции |

## 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)