Ревизия и очередь работ#
Две ревизии: первая — на середине работы, по составу тем; вторая — после завершения, по фактическому состоянию текста. Обе проводились измерением, а не чтением по диагонали. Ниже — текущая работа, затем обе ревизии и метрики.
Текущая работа · документы решений#
Начато: 2026-09-16. Третий жанр в документе: карточка объясняет механику, шаг workflow задаёт порядок, документ решения ведёт к выбору и к записи в ADR.
Почему отдельный жанр, а не раздел в карточке#
Три причины, каждая проверяема:
- Разная скорость старения. Механика не меняется, рынок меняется. Лицензия Redis сменилась в 2024, Elasticsearch — в 2021 и снова в 2024, MongoDB — в 2018. Держать такие факты в карточке значит гарантированно иметь устаревшую карточку; в документе решения они собраны в один раздел с датой съёмки.
- Разный момент использования. Карточку читают, чтобы понять; документ решения открывают, когда надо выбрать сегодня и объяснить завтра.
- Разная единица. Карточка — одна тема. Решение обычно пересекает несколько карточек (выбор хранилища трогает DATA-01, DATA-02, DATA-03, DATA-05, DATA-15) и при этом не покрывает ни одну целиком.
Форма#
Шаблон в decisions/00-template.md: отбор по двум осям (цена изменения × влияние), правила заполнения, семь разделов, пять пунктов проверки. Пункты проверки живут в шаблоне, а не дублируются в каждом документе.
Рыночный слой заполняется только проверенными фактами со ссылкой на первоисточник; непроверенные строки несут пометку [не проверено] и не могут служить дисквалификатором. Пометка оставлена намеренно — она честнее, чем видимость проверенной таблицы.
Версионирование#
Введено 2026-09-16, decisions/02-versioning.md v1.0. Две цифры вместо трёх: MAJOR — метод изменился так, что прежнее решение могло бы выйти другим; MINOR — всё остальное. Рыночный слой версионируется датой съёмки, а не номером. ADR не версионируется вовсе: у него статус и замена, потому что версия у записи о прошлом означала бы, что прошлое можно переписать.
Запрос на версионирование вскрыл дыру: шаблона ADR не существовало, а 00-workflow.md содержал свой инлайновый вариант, уже разошедшийся с полями раздела 6 в D-01 и D-02. Канонический шаблон заведён (01-adr-template.md v1.0), инлайновый из W11 убран и заменён ссылкой.
Схема сразу отработала на первом же реальном изменении: D-02 ушёл в v2.0 (MAJOR), потому что ось «транзакционные разрывы» стала заполняться ценой, а не количеством, — ранжирование кандидатов от этого может перевернуться. Запись в истории версий содержит инструкцию «старым ADR: пересчитать сравнение, если у кандидатов разное число разрывов».
check.py расширен проверкой цепочки версий: строка версии в каждом файле decisions/, совместимость по MAJOR с мастер-шаблоном, соответствие верхней строки истории версий заявленному номеру. Проверен негативным тестом на трёх подсаженных ошибках — все три пойманы.
План итераций#
| № | Документ | Что проверяет в форме | Статус |
|---|---|---|---|
| 1 | 00-template.md + D-01 · Выбор хранилища |
Полный случай: максимум осей, богатый рынок, отложить реально возможно | ✅ сделано |
| 2 | D-02 · Границы сервисов |
Вырожденный случай: рыночного слоя нет вовсе — что в шаблоне окажется лишним | ✅ сделано |
| 3 | D-03 · Стратегия кэширования |
Короткая форма: обратимо, но с высоким влиянием на экономику | ✅ сделано |
| 4 | D-04 · Связь сервисов в рабочем процессе |
Третий тип: варианты перечислены моделью, множество закрыто и полно | ✅ сделано |
После трёх итераций — решение о том, сколько документов заводить всего и какие разделы шаблона сокращать. Раньше трёх решать нечего: одна форма на одном примере всегда выглядит удачной.
Что показала итерация 3#
Проверялась клетка «дёшево изменить × высокое влияние». Шаблон описывал её одной строкой — «короткая форма: разделы 1, 2, 5». Строка оказалась неверной: короткая форма не является полной минус разделы, это другая форма.
У обратимого решения другая задача. Не «выбрать правильно», а не ошибиться катастрофически, быстро узнать об ошибке и суметь откатиться. Отсюда четыре расхождения:
| Полная | Короткая | |
|---|---|---|
| Сравнение | Матрица: оси × варианты | Умолчание и таблица отклонений — варианты не равноправны, один заведомо разумен |
| Что мерить / когда пересматривать | Два разных места | Один раздел: показатель и есть условие возврата |
| Запись | ADR со снимком матрицы | Пять строк |
| Срок пересмотра | По событию | Не назначается — пересматривает метрика, а не календарь |
Самая существенная находка — не структурная. Правило «нет данных» меняет смысл на противоположный в зависимости от обратимости. В D-01 пустая ячейка означает «не решать, пока не измерим»: выбор хранилища наугад закрепляет незрелое решение. В D-03 — наоборот: включить умолчание на части трафика и померить дешевле, чем анализ, который ту же цифру только оценит. Это единственное место, где формы расходятся по существу, а не по объёму.
Отрицательный результат. Ожидалось, что у короткой формы не будет рыночного слоя, потому что обратимые решения не про продукты. Неверно: у кэширования рынок есть (Redis, Valkey, Memcached, CDN). Слоя нет по другой причине — выбор продукта это отдельное решение полной формы, и он уже покрыт рыночной таблицей D-01. Правило переформулировано в шаблоне.
00-template.md → v2.0 (MAJOR: изменился состав разделов короткой формы и правило заполнения). Перепроверять нечего: D-03 — первый документ по короткой форме. 01-adr-template.md → v1.1 (MINOR: добавлена короткая запись). D-01 и D-02 сверены с новым мастером — содержательных изменений не потребовали, обновлена только строка совместимости.
Что показала итерация 2#
Проверка на вырожденном случае ожидалась как сокращение шаблона: думал, что раздел 4 просто исчезнет, а форма окажется избыточной. Вышло наоборот — ничего лишнего не нашлось, зато нашлось недостающее, и разделилось надвое то, что считалось единым.
Главное различие, которого в шаблоне не было: варианты либо берут готовыми, либо строят. Оно меняет три раздела из семи, и первая версия шаблона молча предполагала первый случай.
| Что предполагалось | Что оказалось |
|---|---|
| Раздел 4 отсутствует, если решение не про выбор продукта | Раздел не исчезает, а меняет форму: вместо рынка — типовые формы разреза. Даты съёмки у них нет: формы не устаревают, устаревают продукты |
| Раздел 1 собирает факты для осей | Когда вариантов нет на рынке, он же их и порождает: разные принципы разреза, применённые к одним фактам, дают разных кандидатов. Совпадение линий у разных принципов — сильнейший сигнал верной границы |
| Словарь пометок один на все решения | Словарь свой у каждого решения. Там, где вендорской документации нет, [док] не встречается вовсе, а факты берутся из репозитория, схемы и требований. Универсально только правило «ячейка без пометки непроверена» |
| Нулевой вариант подразумевается | Он обязан быть колонкой. Кандидатов, которых строишь сам, легко построить все «интересными» и не заметить, что ничего делать не надо |
Все четыре находки перенесены в 00-template.md; D-01 получил недостающую колонку нулевого варианта.
Побочный результат: документ решения без рынка оказался проверяемее документа с рынком. Факты для D-01 приходится брать из чужой документации и верить ей; факты для D-02 лежат в собственном репозитории и считаются за час. Это переворачивает ожидание, что «мягкие» решения хуже обоснованы.
Гипотеза: третий тип решений#
Возникла при разборе трёх сил Форда и Ричардса (взаимодействие · согласованность · координация). Восемь сочетаний — это закрытое множество, полное по построению: три двоичных выбора, больше вариантов не бывает.
| Тип | Откуда варианты | Множество | Стареет |
|---|---|---|---|
| Берут | С рынка | Открытое | Да |
| Строят | Из наших фактов | Открытое | Нет |
| Перечисляют | Из модели | Закрытое, полное | Нет |
У третьего типа есть свойство, которого нет у двух первых: можно быть уверенным, что вариант не упущен. Предположительно это меняет раздел 3 — колонок не восемь, вместо сравнения происходит позиционирование: не «какой вариант лучше», а «в какой ячейке мы находимся и устраивает ли она нас».
Гипотеза проверена итерацией 4 и внесена в шаблон v3.0 — см. ниже. Исходная запись оставлена как есть: она показывает, что предполагалось до проверки.
На момент записи гипотеза не была проверена. Дисциплина, принятая после итерации 2: находка о форме приходит из написанного документа, а не из рассуждения о том, каким он мог бы быть. Проверяется итерацией 4 — D-04 · Связь сервисов в рабочем процессе, где эти восемь сочетаний и будут разделом 4.
Что показала итерация 4#
Гипотеза о третьем типе подтвердилась, причём сильнее, чем предполагалось: расхождения оказались не в одном разделе, а в пяти правилах.
| Правило, считавшееся общим | Как оно выглядит в перечисляемом типе |
|---|---|
| Ось, по которой варианты не различаются, вычёркивается | Координатную ось убрать нельзя: получится не более простое решение, а неопределённая ячейка |
| Дисквалификатор отсекает вариант | Отсекает сочетание требований: ячейку нельзя отвергнуть, не отвергнув то, что в неё привело |
| Нулевой вариант — обязательная колонка | Не бывает: в какой-то ячейке система находится всегда |
| Матрица копируется в ADR снимком | Копировать нечего — перечень не зависит от рынка; снимком идут ответы на координатные вопросы |
| «Нет данных» — повод померить | В координатном вопросе не бывает: это не нехватка данных, а неопределённое требование, и возвращаться надо к W0 |
Побочное обобщение, которого не было в плане. Семь разделов — это полная форма, а обе остальные сливают пару, и пары разные: короткая форма сливает «что мерить» с «условиями пересмотра», перечисляемая — «матрицу» с «из чего выбирают». В обоих случаях два раздела перестают быть разными вопросами. Правило внесено в шаблон.
Ещё одно наблюдение, пока без вывода. Решения делятся не только по происхождению вариантов, но и по частоте применения: D-01 и D-02 принимаются один раз на систему, D-03 — по разу на узкое место, D-04 — по разу на процесс. Повторяемые обязаны быть дешёвыми в применении, и обе «шестираздельные» формы оказались именно повторяемыми. Возможно, это и есть настоящая причина сокращения, а тип вариантов — вторичен. Проверять не на чем: нужен повторяемый документ первого типа или однократный третьего.
Сквозной прогон на кейсе#
Начат 2026-09-16. После четырёх итераций форма документов решений устоялась — три типа, два варианта слияния разделов. Но проверялась она четыре раза против воображения автора и ни разу против конкретной системы: во всех документах стоит оговорка «пример условный, числа выдуманы», а стыки между ними (поля ADR, словари пометок, нумерация) согласованы только потому, что их так написали.
Прогон берёт кейс CASE-08 бронирование билетов из блока B12 и проводит его через всю цепочку, с настоящими числами и настоящими ADR. Живёт в examples/E-01-booking/.
| Этап | Что | Статус |
|---|---|---|
| 1 | Вход: рамки, числа, инварианты (W0, W1) | ✅ 00-context.md |
| 2 | D-01 → ADR-0001, выбор хранилища | ✅ ADR-0001-storage.md, 6 находок |
| 3 | D-02 → ADR-0002, границы сервисов | ✅ ADR-0002-boundaries.md, 4 находки |
| 4 | D-04 → ADR-0003, связь в процессе «резерв → оплата» | ✅ ADR-0003-workflow-coupling.md, 4 находки, две — противоречия в уже написанном |
| 5 | D-03 → ADR-0004, кэш схемы зала | ✅ 4 находки, включая противоречие внутри D-03 |
| 6 | Ревизия прогона и правки в шаблоны | ✅ 14 правок внесены, D-02 разделён, реестр перенесён в метод |
Что прогон должен дать, чего не дают отдельные документы: проверку стыков, замер стоимости применения (повторяемые документы обязаны быть дёшевы), и заполненный образец, которого читателю сейчас негде взять.
Почему именно кейс из B12, а не выдуманная система: кейс уже разобран карточкой, у него есть источники и порядки величин, и расхождение между разбором и тем, что даст прогон, само по себе будет находкой.
Расширение на другие кейсы — после E-01#
Один кейс проверяет одну траекторию. E-01 занимает вполне определённый угол пространства: дефицитный ресурс, жёсткая атомарность, экстремальный пик, ничтожный объём, одна команда. Целые оси документов на нём не работают, и это видно уже после второго этапа.
Кейсы подобраны так, чтобы быть максимально непохожими на E-01 по осям, которые документы используют, а не просто «ещё примеры»:
| Кейс | Что проверит, чего не проверяет E-01 | |
|---|---|---|
| E-02 | CASE-02 лента новостей | Противоположность почти по всем осям: объём большой, согласованность итоговая, дефицитного ресурса нет. D-04 попадёт в другую половину пространства, D-03 понесёт основную нагрузку вместо вспомогательной |
| E-03 | CASE-10 геопоиск или CASE-07 видео | Рыночный слой заработает по-настоящему: специализированное хранилище выбирается не по привычке, лицензии и жёсткие лимиты становятся действующими дисквалификаторами. У видео вдобавок исходящий трафик — доминирующая статья расходов, то есть настоящая экономика для короткой формы |
| E-04 | CASE-12 мультитенантный SaaS | Организационные оси D-02: в E-01 команда одна, и половина осей разреза вырождается в «неприменимо» |
Порядок: сначала закончить E-01 целиком. Начинать второй кейс до шестого этапа первого — та же ошибка, от которой отказались при выборе направления: ширина раньше проверки. Находки E-01 изменят шаблоны, и E-02 стоит проходить уже по исправленным.
Инфраструктурные работы идут попутно, а не отдельным этапом: индекс решений по шагам добавлен в README на первом этапе; реестр организационных ограничений заведён на втором этапе — examples/E-01-booking/constraints.md, четыре записи из первого же ADR. check.py расширен проверкой ADR: статус из словаря, метод ссылается на существующий документ решения и на версию, которая есть в его истории. Прогнан негативным тестом.
Принято: стадия проекта — отдельное решение, а не ветка#
2026-09-16, по ходу прогона. Если на разных стадиях проекта решение принимается по-разному, это разные решения в разных документах. Условная ветка внутри документа размывает его ответственность: читателю надо сначала понять, в какой он ветке, а способа понять документ не даёт.
Разделяющий признак, чтобы набор не расплодился: разделять, когда меняется источник фактов, дисквалификаторы или эвристики; не разделять, когда меняются только значения в ячейках. На данных прогона признак различил D-01 (не разделять — метод тот же, поменялся только словарь пометок) и D-02 (разделять — на гринфилде нет источника фактов, эвристика даёт невыполнимую инструкцию).
Стадий предположительно три: гринфилд · работающая система · система под изменением (есть работающая система и обязательство её не сломать: миграция, совместимость, окно перехода, откат). Третьей в decisions/ нет вовсе, а именно на ней принимается большинство решений в живых проектах.
Именование: отдельные номера плюс строка «Не путать с» в шапке — не буквенные суффиксы D-02a/D-02b, которые провоцируют прочесть только один документ. Подробный разбор — в examples/E-01-booking/99-findings.md.
Проверить на E-02: если правило начнёт делить всё подряд, разделяющий признак слишком слабый.
Итог ревизии по прогону E-01#
Восемнадцать находок дали четырнадцать правок — на три больше, чем обещал план: при исполнении выяснилось, что находки 2, 12 и 13 в разделе «делаю сам» пропущены, хотя развилки не содержат. Записано как есть, потому что это ровно та ошибка, от которой защищает разбор по пунктам: список, составленный по памяти, теряет три позиции из восемнадцати.
| Документ | Было → стало | Главное изменение |
|---|---|---|
00-template.md |
v3.0 → v4.0 | Три степени достоверности факта вместо двух: появился [расчёт]. Организационные дисквалификаторы вперёд технических. Короткая форма и короткая запись разделены. Исправлено опровергнутое утверждение о нулевом варианте |
01-adr-template.md |
v1.1 → v1.2 | Раздел «самая дорогая будущая граница»; снят ложный сигнал о длине записи |
D-01 |
v1.0 → v1.1 | Порог реестра ограничений; «Не решает» и «Не путать с» |
D-02 |
v2.1 → v3.0 | Сужен до работающей системы; проверка разреза по профилю нагрузки |
D-05 |
— → v1.0 | Новый: границы на старте. Выделен из D-02 по позиции о стадиях |
D-03 |
v1.0 → v2.0 | Развилка «инвалидация против короткого TTL» впереди умолчания; снято внутреннее противоречие |
D-04 |
v1.0 → v2.0 | Применимость по границе без общей транзакции; третье значение оси согласованности; разбор процесса на участки |
03-constraints-registry.md |
— → v1.0 | Форма реестра перенесена из прогона в метод |
Правки в check.py: проверка ADR (статус из словаря, метод ссылается на существующую версию) и проверка ссылок, уходящих за пределы дерева. Вторая появилась потому, что первая же собственная ошибка в новом D-05 — ../../ вместо ../ — прошла мимо проверок незамеченной. Обе прогнаны негативным тестом.
ADR прогона намеренно не переписаны. ADR-0001…0004 указывают на D-01 v1.0, D-02 v2.1, D-03 v1.0, D-04 v1.0 — версии, которые действительно применялись. Истории версий говорят, что изменилось и что перепроверить. Это первое настоящее применение версионирования по назначению; переписать ADR значило бы стереть единственное свидетельство того, как метод работал до правок.
Отложено сознательно: D-06 · Деградация и поведение при отказе — решение, которое потребовал дисквалификатор D-03 на этапе 5. Причина отсрочки: сейчас проверяются изменённые документы, и новый документ расширил бы комбинаторику того, что подлежит проверке.
Дальше: E-02 «Лента новостей» — противоположный угол пространства, на нём проверяются все четырнадцать правок и разделяющий признак для стадий.
Прогон E-02 · Лента новостей#
Начат 2026-09-16. examples/E-02-feed/.
Кейс взят работающей системой, а не гринфилдом — это решение, принятое при подготовке, и оно расширяет проверку: E-01 прошёл по D-02 v2.1 и породил D-05, E-02 пройдёт по D-02 уже суженному. Проверяются обе половины разделения и сама позиция о стадиях.
| E-01 | E-02 | |
|---|---|---|
| Стадия | Гринфилд, факты предсказываются | Работающая система два года, факты измеряются |
| Дефицитный ресурс | Есть | Нет |
| Согласованность | Атомарная, местами недостижимая | Итоговая по построению |
| Объём | Ничтожен | Решает: 320 ГБ в памяти |
| Нагрузка | Пик ×1000 полчаса в неделю | Ровная, пик ×10 |
| Команда, наблюдаемость | Одна команда, ничего нет | Три команды, платформенная есть, всё построено |
Почти все дисквалификаторы, сработавшие в E-01, здесь не сработают — и это нужно: документ, который на одном кейсе всё отсекает, а на другом ничего, проверен вдвое лучше, чем испытанный дважды в одинаковых условиях.
Что проверяется прицельно: пометка [замер] вместо [расчёт] — здесь измерения есть · раздел 1 D-02 с настоящей историей изменений · ось «стоимость владения», впервые заполняемая не пометкой [нет данных] · развилка «инвалидация против TTL» на кэше, где ключей миллионы, а не один.
| Этап | Что | Статус |
|---|---|---|
| 1 | Вход: рамки, числа, инварианты | ✅ 00-context.md |
| 2 | D-01 v1.1 → ADR-0001 | ✅ 3 находки; правка «[нет данных] в различающей оси» изменила исход решения |
| 3 | D-02 v3.0 → ADR-0002 | ✅ 2 находки; история изменений опровергла существующий разрез |
| 4 | D-04 v2.0 → ADR-0003 | ✅ 5 находок; процесс оказался не сагой, и восемь ячеек не дали ничего |
| 5 | D-03 v2.0 → ADR-0004 | ✅ 4 находки; главная развилка сработала в сторону, противоположную E-01 |
| 6 | Ревизия: 20 находок в правки | ✅ 98-revision-plan.md, исполнено 2026-09-17 |
Итог ревизии по прогону E-02#
Двадцать находок: 16 из прогона, 4 из разбора глав 6–7 Форда и Ричардса. Ни одна правка E-01 не откатилась, одну прогон не смог проверить — случая не возникло.
| Находка | Стало | Где |
|---|---|---|
| Соотношение чтений к записям не переносится с системы на хранилище | Вопрос 2 спрашивает про это хранилище; системное — контекст, не ответ | D-01 v2.0 |
| Объём бывает параметром, а не данностью | Сначала параметр и метрика, потом ось; иначе [нет данных] |
D-01 v2.0 |
| Нет вопроса о существующей декомпозиции | Вопрос добавлен; текущий разрез проходит дисквалификаторы наравне с кандидатами | D-02 v4.0 |
| Порог связности изменений не назван | ~80 % как ориентир для разговора, не критерий приёмки | D-02 v4.0 |
| Поддомен и ограниченный контекст свалены в одну форму | Две формы, разные пространства — задачи и решения | D-02 v4.0 |
| Критерий «по языку» не опознаётся без имени | Назван единый язык Эванса; критерий — метод, а не наблюдение | D-02 v4.0 |
| Граница без общей транзакции описана только организационно | Распространена на два хранилища внутри одного сервиса | D-04 v3.0 |
| Дисквалификатор «дольше часа» меряет не тот параметр | Произведение длительности на частоту | D-04 v3.0 |
| Восемь ячеек предполагают сагу; раздача — размножение шага | Явный отвод плюс таблица «сага против размножения» | D-04 v3.0 |
| «Число участников» не считает потребителей общей шины | Считаются и независимые потребители события; каталог подписчиков обязателен | D-04 v3.0 |
| У вопроса об инициаторе есть третий ответ | Назван: инвариант закрывается на другом пути | D-04 v3.0 |
| Дисквалификатор «устарелость недопустима» = умолчание теми же словами | Разведены по режиму эксплуатации: TTL как граница ущерба, сверка выборкой, отдельный показатель | D-03 v3.0 |
| Таблица отклонений молчит о наложении | Складывать можно, цены пересчитываются, а не суммируются | D-03 v3.0 |
| У локального кэша названа не вся цена | Вторая половина — холодный старт на каждом выкате, прогрев обязателен | D-03 v3.0 |
| Применения документа не независимы | Временно: один ADR с общим контекстом; общая форма — в очереди, см. «мастер-решение» | D-03 v3.0 |
D-02 не различает модульность и гранулярность |
Введено различение; отмечено, что дисквалификаторы у них разные | D-02 v4.0 |
| Нет сил интеграции как половины решения | Четыре вопроса и встречный список с правилом «оплачена ценой или отменяет линию» | D-02 v4.0, отражено в D-01 v2.0, D-03 v3.0, D-05 v2.0 |
| Декомпозиция данных — решения нет | Две силы-минимума в D-01; полный документ — в очереди |
D-01 v2.0 |
| Архитектурный квант нигде не проверяется | Дисквалификатор: разные цели по доступности внутри одного кванта недостижимы | D-02 v4.0, D-05 v2.0 |
| Третий режим «применим и бесполезен» | Придержано до исследования — в мастер-шаблон не поднято | — |
Пять документов решений из пяти набрали на MAJOR по итогам второго кейса. Правки E-01 были верны — ни одна не откатилась, — но сделаны по одному случаю. Если третий прогон снова даст MAJOR всем, это будет означать не «нашли ещё», а отсутствие сходимости формы, и тогда форму надо менять, а не дополнять.
Принято по итогам E-02: связанные решения и множественность применений#
- Мастер-решение. Бывает решение, состоящее из нескольких независимых: «транзакционное решение» из связки, два кэша на одном пути чтения, границы плюс связь плюс кэш вокруг одного параметра. Нужна форма, удерживающая сумму, а не только слагаемые. Пока не вводится: ждёт исследования.
- Несколько решений по одному шаблону — норма. Правила «шаг содержит одно решение» нет и не было; разумная гранулярность применений — часть метода. Зафиксировано явно в
D-03иD-04. - Очередь новых документов закрыта.
D-06 · Деградация при отказе и перегрузке— написан пилотом И0;D-07 · Декомпозиция данных— пилотом И0′, оба 2026-09-17. Оба документа и оба отчёта о методе получены за два пилота, как и планировалось. - Принято при разборе И0′: удаление персональных данных — частный случай согласованности данных, а не отдельная тема: изменение обязано дойти до всех копий, удаление — такое же изменение. Но класс защищаемых данных влияет и на границы, поэтому он добавлен в
D-02 v5.0иD-05 v3.0вопросом, дисквалификатором и формой разреза. - Сигнал о размере
D-02: вопросов стало одиннадцать при верхней границе в семь. Кандидат на разделение по линии модульность / гранулярность. Не делим: признак виден на двух случаях, и оба наши.
Очередь документов решений — по итогам исследования#
Заменяет прежнюю очередь, собранную по случаям из прогонов. Тридцать записей реестра дали четыре документа к написанию: критерий общности и слияния сократили список вдвое против того, что виделось после сбора.
| # | Документ | Основание |
|---|---|---|
| ✅ | D-08 · Миграция данных без остановки | Написан 2026-09-17. Данные: изменение системы даёт 37,2 % инцидентов против 21,5 % у кода. Первый документ третьей стадии |
| ✅ | D-09 · Обратимость выката | Написан 2026-09-17. Предмет сужен: стратегии выката остались карточкой, здесь решается существование отката |
| ⊘ | Не устоял как отдельный документ. OPS-07 и OPS-08 содержат все три признака карточки, делающей работу решения; решающая часть — какие вопросы система обязана уметь отвечать — вошла в D-10 |
|
| ✅ | D-10 · Цели уровня обслуживания и их измерение | Написан 2026-09-17, вобрал предыдущую строку: нельзя обещать то, чего не измеряешь, и незачем измерять то, чего не обещаешь |
Первые два вместе закрывают третью стадию — «систему под изменением», которой в наборе не было вовсе.
Отложены до подтверждения: совместимость контракта · модель авторизации · лимитирование. Держались на одном каноне без независимого подтверждения; по собственному правилу такие записи в реестре остаются, а документов по ним не пишут.
Первый из троих вышел из отложенных 2026-09-17. Мини-исследование М1 нашло подтверждение P-API-01 в данных — пять работ по эволюции API, из них четыре с выборками в сотни тысяч клиентов. Ждали третьего кейса, а хватило одного этапа поиска; отсюда правило на будущее: отложить «до прогона» значит отложить до случая, и оставшихся двоих стоит проверить тем же способом. Мини-исследование дало и шестую поправку к правилу допуска источников — о данных из соседней популяции.
| Кандидат | Состояние |
|---|---|
P-API-01 совместимость контракта |
✅ Написан 2026-09-18 — D-11 · Обещание совместимости интерфейса. Предмет сужен карточным правилом: NET-17 и NET-18 описывают, как держать совместимость; решается, какое обещание даётся и сколько стоит знание о потребителях |
P-ACC-02 модель доступа |
✅ Подтверждён, документа не будет (М2, 2026-09-18). Данные подтвердили SEC-04, а не нужду в документе: нарушенное управление доступом — первая категория OWASP Top 10 2021 по числу случаев, три записи про авторизацию в CWE Top 25, и обе стороны говорят то, что в карточке уже написано |
P-ACC-01 лимитирование |
✅ Подтверждён, документа не будет (М3, 2026-09-18). EDGE-06 несёт больше, чем короткая форма документа; разборы GitHub поправили саму запись — усиливает чаще свой же сервис, и вопрос не «есть ли лимит», а «срабатывает ли он сам» |
Отложенных не осталось. Критерий прошли все трое, документ вышел один — и это результат про метод: «общая ли проблема» и «есть ли что решать сверх карточки» оказались разными вопросами. Разбор — в итоге М1–М3, там же проверяемая гипотеза о жанре: меню механизмов — карточка; граница, обещание и необратимость — документ.
Очередь после мини-исследований — остатки к раздаче#
Мини-исследования дали не только вердикты, но и куски, которым нашлось место в уже написанном. Разведены по вариантам и отвечены 2026-09-18 — 98-revision-plan.md.
| Куда | Что добавить | Откуда | Состояние |
|---|---|---|---|
00-template.md |
Дисквалификатор семейства обещаний | D-11 |
✅ v6.0 |
00-template.md |
Гипотеза о жанре | Итог М1–М3 | ✅ v6.0, вопросом; проверяется предсказаниями |
00-template.md |
Обобщить формулу третьего типа | D-11 |
✅ v6.0 |
| Процесс | Новый документ читает кто-то, кроме автора, по списку из семи пунктов | D-11 |
✅ v6.0 |
| SEC-04 | Проверяемый порог: одно исключение — предупреждение, три — модель выбрана не та | М2 | ✅ внесено 2026-09-18 |
| EDGE-06 | Ключ важнее величины; усиливающий потребитель чаще внутренний; ограничитель, включаемый руками, — средство восстановления | М3 | ✅ внесено, с источником |
| D-02 | Граница режет решение о доступе | М2 | ❌ отклонено прогоном (Пр-4 — промах): границы резались, вопрос не возник. Возвращено в отложенные до кейса с объектной авторизацией |
Карточки SEC-04 и EDGE-06 |
Направление отказа: куда падать, когда проверяющий недоступен | М2, М3 | ✅ внесено, и обогащено прогоном: направление — свойство операции и её инварианта, а не системы |
Разобрано прогоном E-03 2026-09-18. Отложены они были намеренно (П9·B), чтобы кейс их подтвердил или отклонил. Один подтверждён и обогащён, один отклонён, о двух кейс не высказался — внесены по прежним рекомендациям. Механизм сработал ровно так, как задумывался, и стоил трёх непроверенных предсказаний из шести.
Следующая работа — узкий прогон третьей стадии#
Решено развилкой Е7·B 2026-09-18.
Из одиннадцати документов набора четыре не применялись ни разу: D-05, D-08, D-09, D-11. Утверждение «форма сошлась», полученное на E-03, относится к семи из одиннадцати.
Формат — узкий прогон, а не сквозной: два-три ADR по D-08 и D-09. Кандидат Б-3 из списка, предложенного со стороны.
Пройден 2026-09-18 — U-01. Два ADR, шесть безусловных предсказаний, четыре попадания и два промаха. Оба впервые применённых документа потребовали MAJOR: D-08 не различает операционную и информационную обратимость, D-09 требует одну степень обратимости там, где их три. Неприменённых осталось два из одиннадцати — D-05 и D-11.
Что теперь в очереди#
| Что | Класс | Откуда |
|---|---|---|
D-08 · различить операционную и информационную обратимость |
MAJOR | ✅ v2.0 2026-09-18 |
D-09 · степень обратимости по строкам состояния мира |
MAJOR | ✅ v2.0 2026-09-18 |
| Запись в реестр проблем о границе между организациями | новая запись | ✅ P-CHG-04 — первая запись, добавленная работой, а не опросом поля |
| Перед планированием читать строки «не решает» | процесс | ✅ мастер-шаблон v6.1 |
Всё внесено 2026-09-18. У обоих MAJOR строка «что перепроверить в старых ADR» оказалась одинаковой и неожиданной: перепроверять нечего, потому что до U-01 ни один из двух документов не применялся ни разу.
Что теперь открыто#
| Что | Почему висит |
|---|---|
P-CHG-04 · данные ушли в чужую организацию, и проверить там нечего |
Ни один документ набора не обслуживает то, что после передачи. D-08 и D-09 закрыли перенос. Известные решения в записи почти все договорные, и это само по себе наблюдение |
D-05 и D-11 не применялись ни разу |
Два документа из одиннадцати. После U-01 известно, чего стоит первое применение: два документа — два MAJOR |
| Гипотеза о жанре | По-прежнему в мастер-шаблоне вопросом. Первое проспективное предсказание записано в P-CHG-04: предмет выглядит обещанием и необратимостью, а не меню механизмов. Проверится, если запись дойдёт до документа |
Повторное применение D-08 и D-09 |
Сходимость измеряется повторами. У этих двух были только первые |
| > | |
> Правка D-06 из прежней редакции этой таблицы отменена. Разбор показал, что новых форм деградации там нет: «предохранитель отбросил запрос» — имеющийся «явный отказ», а «служба решений недоступна» — не форма, а зависимость, которую третий вопрос D-06 уже обслуживает. Осталось сопоставление направлений отказа, и оно карточное. |
Что из этого делать — 99-plan.md: четыре шага с вариантами, пятый назван и отложен, и развилка «метод или назначение».
D-11 прошёл независимую рецензию до первой записи#
Документ был написан, а затем проверен отдельным агентом, не видевшим, как он писался, — по мастер-шаблону, по карточкам NET-17/NET-18, по эталону третьего типа D-04 и по источнику фактов М1. Рецензия нашла и вернула на правку:
| Что нашлось | Почему это важно |
|---|---|
| Пересказ карточки в эвристике — «снимают по нулевому трафику, а не по истечении срока» есть в NET-17 теми же словами | Документ, чья шапка обещает карточку не пересказывать, пересказал её в третьем же правиле. Заменено на то, чего в карточке нет: на какой глубине это правило исполнимо |
| Пропала оговорка о возрасте цифр, хотя М1 ставит её первой | Числа 2011 года шли настоящим временем; встречный результат реплики (83,4 % соблюдения, растёт) был опущен. Обе стороны возвращены |
| «Всё измерено на пакетах» — на самом деле четыре работы из пяти | Документ опровергал собственную оговорку двумя абзацами ниже, пользуясь пятой работой |
| Выброшена верхняя четверть (13,10 % при медиане 2,54 %) | Опущение ровно в ту сторону, куда наклонён вывод |
Координата T в четырёх смыслах сразу |
Определена однозначно: нижняя граница предупреждения, а не дата снятия |
| Три объявленные и незаполненные оси сравнения | В третьем типе их не бывает — убраны, цены живут в таблице выхода из ячейки |
| Дисквалификаторы отсекали ячейки, чего в третьем типе делать нельзя | Переписаны так, что отвергается требование, а не ячейка — как в D-04 |
Это первый документ набора, прошедший внешнюю проверку до принятия, и стоило это одного прогона. Шесть находок из семи — не вкусовые, а проверяемые по источникам; половина из них ловится тем же правилом, которое документ сам провозглашает в шапке. Вывод для метода: автор не может проверить документ на пересказ карточки — он её только что читал.
Ответ на вопрос о сходимости трёх обещаний — 2026-09-18#
В М1 записано: если три документа об обещаниях сойдутся по осям и дисквалификаторам, это скажет о шаблоне больше, чем ещё один кейс. D-11 написан, проверка проведена.
Оси не сошлись, и близко. У D-06 — класс важности, инвариант, суррогаты, порядок деградации. У D-10 — показатель, цель, бюджет ошибок, цена девятки. У D-11 — знание о потребителях, срок, охват. Общих осей нет ни одной.
Форма не сошлась тоже: D-06 и D-10 полные, D-11 перечисляемый — второй документ третьего типа после D-04.
Сошлось ровно одно — и это дисквалификатор. Он есть у всех трёх, а если считать D-09 четвёртым обещанием (откат — обещание команде), то у четырёх из четырёх:
| Документ | Как звучит у него |
|---|---|
D-06 |
Путь деградации ни разу не исполнялся: механизм, который не исполняется, не работает |
D-09 |
Откат ни разу не исполнялся — значит, это предположение, а не возможность |
D-10 |
Измеритель не показывает число сегодня — значит, обещать нечего |
D-11 |
Совместимость не проверяется машиной; срок объявлен, а объявить некому |
Обещание, исполнение которого нечем установить, обещанием не является.
Предложение: записать это в мастер-шаблон один раз — как обязательный дисквалификатор для любого документа, предмет которого обещание, — чтобы следующий такой документ не открывал его заново. Шестая местная проверка у всех трёх тоже об одном и том же: обещание должно быть выражено так, чтобы его можно было предъявить. Решение за тобой: это восьмая правка шаблона, и по нынешнему счёту она первая, которая обобщает, а не исправляет.
Не порождает документа: стиль взаимодействия. NET-08 делает большую часть работы документа решения — сравнение, умолчание, область, главный вопрос; недостающее принадлежит соседним решениям.
Недостающие карточки — очередь закрыта 2026-09-17#
Все четыре найденные исследованием пробела закрыты пачкой, как и планировалось: карточка, написанная посреди пилота, вышла бы из того куска темы, который в тот момент открыт.
| Карточка | Откуда пробел | Что вышло |
|---|---|---|
| REL-11 · Метастабильные отказы | Пилот И0, P-DEG-01 |
Три состояния системы, четыре усиливающих контура, главный неизмеряемый показатель — время возврата к норме после снятия нагрузки |
| REL-12 · Серый отказ | Пилот И0, P-DEG-06 |
Дифференциальная наблюдаемость, парадокс избыточности, расхождение долей успеха как измеримый признак |
| SEC-13 · Классификация данных и режим защиты | Пилот И0′ | Четыре класса и что каждый обязывает; опора для дисквалификатора в D-02 v5.0 |
| OPS-17 · Когнитивная нагрузка команды | Реестр И1, P-ORG-01 |
Три вида нагрузки; считать домены, а не сервисы |
| Правка PERF-06 | P-DDEC-07, уточнено на И3 |
Добавлен множитель: предел по соединениям — произведение сервисов на экземпляры на размер пула |
Карточек стало 155. Четыре последние найдены исследованием, а не плейлистом и не прогонами — кейсы их показать не могли, потому что в кейсах нет эксплуатации.
Открытые вопросы — решать после итерации 3#
- Третий режим работы документа решения — «применим и бесполезен». Координата определяется, и из неё ничего не следует. Придержано до исследования: возможно, оно даст лучшую формулировку, чем одно наблюдение.
- Вопрос в раздел «когда заводить документ» мастер-шаблона: не делает ли существующая карточка большую часть этой работы, и не дешевле ли достроить соседний документ? Найдено при сведении на NET-08 — единственном случае из тридцати, когда карточка содержит сравнение, умолчание, область и главный вопрос. Карточка и решение — разные жанры, но не всегда разные документы.
- Когда запускать третий кейс. Исследование показало, что набор не покрывал поле: шесть дыр против двух, найденных двумя прогонами. Пока известные дыры не закрыты, третий кейс измерит покрытие, а не форму — и снова даст MAJOR всем документам, что будет выглядеть как несходимость, ею не являясь.
-
Форма для мастер-решения. См. итог ревизии E-02 выше.
-
Реестр организационных ограничений. Колонка «статус у нас» с записями «не используем, потому что…» полезна ровно до тех пор, пока живёт в одном месте. Больше десятка таких записей — и их нужно выносить из документов решений в общий реестр, иначе «Mongo не используем» окажется написанным в одном документе и проигнорированным в другом.
- Aliases в глоссарии. Техника из тезаурусов: «известно также как». В документах решений уже применена (строка «Известно также как» в шапке); в
92-glossary.mdпока нет. - Чек-лист как отдельный артефакт. Вопросы раздела 1 принадлежат решению и уже выполняют роль чек-листа сбора данных. Отдельный чек-лист по Гаванде имеет смысл только для точек невозврата — и тогда он должен быть коротким: пять-девять пунктов, читаемых вслух. Кандидат на пересмотр с этой меркой — 23-пунктный список в W11, слишком длинный для формы чек-листа.
Ревизия №2 · документ завершён#
Дата: 2026-09-02 · предмет: 151 карточка, 22 файла, ~79 000 слов.
Метод#
Три скрипта над исходниками: разбор карточек на секции, построение графа внутренних ссылок, сверка с реестром и с плейлистом. Проверялось: распределение объёма, наличие обязательных разделов, число источников, входящие и исходящие связи, покрытие видео, повторное объяснение одних и тех же механик, покрытие карточек справочниками.
Две метрики пришлось переделать: первая версия проверки «есть ли альтернативы» искала заголовок и не видела таблиц сравнения с другими названиями колонок, а проверка использования видео смотрела только карточки и не учитывала workflow. Обе давали ложные находки — цифры ниже получены после исправления.
Что проверено и оказалось в порядке#
Отрицательные результаты важны не меньше находок:
- Целостность ссылок. 0 битых якорей, 0 ID вне диапазона блока, 0 подписей, не совпадающих с целью, 0 дубликатов ID, порядок ID монотонный во всех 12 файлах.
- Видео. Все 103 из 103 упомянуты в документе — 84 в карточках, остальные в workflow и в карте плейлиста. Ни одно не потеряно.
- Дублирования механик нет. Проверялись самые «сквозные» темы: идемпотентность упоминается в 6 карточках, но механизм (ключ, уникальный индекс, хранение результата) объясняется только в NET-16 — остальные ссылаются. То же для outbox, кворумов, саги, backpressure. Опасение, что одно и то же будет объяснено трижды, не подтвердилось.
- Источники. Медиана 4 внешние ссылки на карточку, 369 уникальных источников. Все 137 полноразмерных карточек имеют разделы «Источники» и «Связано».
- Распределение объёма. Медиана по блокам 323–439 слов на карточку — ровно, без выбросов на уровне блоков.
Находки#
P1 · Workflow почти не связан с карточками — ✅ исправлено (итерация D)#
Данные: из карточек на шаги workflow ведут 157 ссылок, обратно — 5. В 00-workflow.md одиннадцать строк «Связано», но пути в них записаны моноширинным текстом (`topics/03-storage-and-data.md#sharding`), а не ссылками — то есть некликабельны. Ещё они указывают на файл целиком, а не на карточку. У шага W11 связей нет вовсе.
Почему это главная находка. Трёхслойная структура обещала: «из шага workflow — ссылки на карточки, из карточки — обратно на шаг». Обратное направление работает, прямое — нет. Ломается основной сценарий: идёшь по процессу проектирования, упираешься в «выбрать ключ шардирования» и не можешь провалиться в тему.
Что сделано (итерация D). Все 14 путей в моноширинном тексте заменены адресными ссылками; каждый из 12 шагов получил 5–8 ссылок на конкретные карточки плюс, где уместно, ссылку на блок целиком; шаг W11 связан с обзором отказоустойчивости, сверкой данных, моделью угроз, SLO и обоими справочниками. Было 5 ссылок workflow → карточки, стало 82; из workflow напрямую достижимы 72 карточки из 151. Побочный эффект: карточка DIST-11 «Карта паттернов» перестала быть недостижимой.
P1 · Девять коротких кейсов без источников — ✅ исправлено (итерация E)#
Данные: CASE-04…CASE-12 — единственные карточки в документе с нулём внешних ссылок и без раздела «Источники».
Почему. Требование «для всего приводи источники» выполнено везде, кроме этих девяти. При том что кейсы — самая прикладная часть, и читателю там особенно нужно, куда идти дальше.
Что сделано (итерация E). В каждый кейс добавлено по три источника — первоисточники и документация по теме (HyperLogLog и Count-Min Sketch для топ-K, RFC 8216 и DASH для видео, H3 и PostGIS для геопоиска, Stripe для платежей и лимитов). Теперь ни одной карточки в документе с менее чем двумя источниками; библиография выросла с 369 до 396 записей.
P2 · Карточки-решения без сопоставления вариантов — ✅ исправлено (итерация F)#
Данные: таблицу сравнения или блок «когда что» имеют 74 из 151 карточки. Среди остальных большинство — описательные (как работает интернет, коды состояния, типовые атаки), где выбора нет и таблица была бы искусственной. Но 16 карточек описывают именно выбор и сопоставления не содержат:
CACHE-04 патологии кэша · MSG-06 гарантии доставки · MSG-08 ретраи и DLQ · ARCH-02 границы сервисов · ARCH-09 serverless · ARCH-10 mesh, sidecar, BFF · SEC-01 сессии против токенов · SEC-08 шифрование · OPS-04 контейнеры · OPS-05 Kubernetes · OPS-07 observability · OPS-11 ёмкость · OPS-12 тестирование · PERF-04 конкурентность · PERF-06 пулы и N+1 · PERF-11 стоимость.
Что сделано (итерация F). Во все шестнадцать добавлены компактные таблицы: варианты исполнения для serverless, три уровня изоляции для контейнеров, три сигнала наблюдаемости, показатели масштабирования, признаки верной и ложной границы, классификация ошибок потребителя. Таблиц сравнения в документе стало 90 вместо 74.
P2 · Десять карточек, на которые никто не ссылается — ✅ исправлено (итерациями D и F)#
Данные: NET-02 (OSI), NET-20 (API vs SDK), DIST-11 (паттерны распределённых систем), OPS-14–OPS-16 (справки о ролях, монорепо, релизе мобильных), CASE-01, CASE-02, CASE-12, CASE-13 (кейсы).
Кейсы — листья по построению, на них и не должны ссылаться. DIST-11 «Карта паттернов» закрыта итерацией D — на неё ведёт шаг W4. Остальные восемь закрыты итерацией F: модель OSI связана из карточки балансировки, API против SDK — из контрактов, роли и монорепозиторий — из CI/CD, релиз мобильных — из версионирования API, а три кейса — из тех карточек, которые они разбирают (уникальные ID → сокращатель ссылок, модели взаимодействия → лента, мультитенантность → SaaS). Карточек без входящих смысловых ссылок не осталось.
Оговорка по методу: «сирота» здесь означает «нет ссылок из текста карточек и из workflow». Навигационные строки в начале каждого блока ссылаются на все карточки своего блока, поэтому формально недостижимых нет ни одной — но через оглавление, а не по смысловой связи.
P3 · Короткие кейсы тоньше остального документа#
Данные: CASE-04–CASE-12 — 131–160 слов при медиане по документу 340–420. Это было сознательное решение («короткий разбор»), но вместе с отсутствием источников они выглядят незаконченными, а не компактными.
Что сделано (итерация E). В каждый кейс добавлен абзац «Порядок величин» с конкретными числами: ячейка H3 восьмого разрешения даёт около семидесяти кандидатов на проверку, вероятностный счётчик уникальных занимает 12 КБ против сотен мегабайт при точном подсчёте, отдельная база на арендатора упирается в эксплуатацию на сотнях экземпляров. Объём кейсов — 208–244 слова при медиане по документу 370.
P3 · Отсутствующие разделы в шести полноразмерных карточках — ✅ исправлено (итерация F)#
Было без «Trade-offs»: NET-01, NET-08, NET-21, SEC-07, PERF-02, PERF-04; без «Что мерить»: NET-02, NET-08, NET-20, NET-21, PERF-01. Все девять разделов дописаны. Без этих разделов остались пять карточек — две обзорные карты (DIST-11, CASE-13) и три подробных кейса (CASE-01–CASE-03), построенных по шагам W0–W7 и имеющих свою структуру. Это осознанное исключение, а не упущение.
P3 · Справочники покрывают документ неравномерно — ✅ исправлено (итерация F)#
Было: 90-cheatsheets.md ссылался на 20 карточек, ни в одном справочнике не упоминались 47. В пять разделов шпаргалки добавлены блоки «Карточки» — теперь она ведёт на 31 карточку, вне справочников осталось 43. Дальше уплотнять смысла нет: оставшиеся карточки либо не сводятся к числу или термину, либо достижимы через workflow и связи внутри блоков.
Очередь работ#
Три итерации, по одному файлу за раз — как и прежде.
| Итерация | Файл | Работа |
|---|---|---|
00-workflow.md |
||
topics/12-case-studies.md |
||
| 8 файлов точечно |
Все три итерации закрыты. Очередь работ по ревизии №2 пуста; открытых находок нет.
Итог ревизии №2#
| Показатель | До | После |
|---|---|---|
| Ссылок workflow → карточки | 5 | 82 |
| Карточек без входящих смысловых ссылок | 10 | 0 |
| Карточек с менее чем двумя источниками | 9 | 0 |
| Таблиц сравнения | 90 | 90 |
| Полноразмерных без «Trade-offs» / «Что мерить» | 11 / 10 | 5 / 5 (обзоры и кейсы) |
| Объём коротких кейсов | 131–160 слов | 208–244 |
| Внешних источников | 369 | 396 |
Следующую ревизию имеет смысл проводить не по расписанию, а по событию: если документ начнут править — добавлять темы, переписывать блоки, — стоит прогнать те же три скрипта и сравнить с этой таблицей.
Ревизия №1 · на середине работы#
Дата: 2026-09-02, при 65 написанных карточках. Предмет — состав тем, а не текст.
Нашла три вида перекоса, унаследованного от плейлиста: инструменты вместо свойств (13 видео про Docker, Kubernetes и Git при нуле про наблюдаемость и ёмкость), транспорт вместо данных на транспорте (версии HTTP разобраны, кэширование и форматы отсутствуют), реляционное вместо остального (ни time-series, ни графовых, ни векторных, ни геоданных).
Итог: добавлено 24 темы — 12 в написанные блоки (закрыты итерациями A, B, C) и 12 в тогда ещё не написанные. Отдельно принято решение оставить короткими справками пять тем (роли DevOps/SRE, монорепо, релиз мобильных, Big-O, сборка мусора), чтобы инструментальный перекос не воспроизвёлся объёмом текста. Решение выполнено: эти карточки — 115–164 слова.
Решено не расширять блок кэширования и не заводить отдельные карточки под Memcached и векторные часы — отрицательные решения тоже часть ревизии.
Метрики документа · снимок на момент ревизии №2#
Числа ниже относятся к состоянию на 2026-09-06, когда были написаны карточки, и намеренно не обновляются: это след ревизии, а не текущее состояние. Текущее берётся из tools/check.py.
| Карточек | 155 в 12 блоках |
| Слов | ~79 000 |
| Файлов | 22 + 2 в decisions/ |
| Из плейлиста / добавлено | 65 / 86 |
| Внешних источников | 396 уникальных |
| Таблиц сравнения | 90 |
| Внутренних связей между карточками | ~600 |
| Ссылок workflow ↔ карточки | 82 / 157 |
| Видео покрыто | 103 из 103 |
Самые цитируемые карточки (входящие связи): MSG-07 outbox (26), EDGE-06 rate limiting (24), NET-16 идемпотентность (23), DIST-08 распределённые транзакции (22), DATA-10 шардирование (21). Это же — список тем, которые окупают внимательное чтение в первую очередь.