Привет, читатель. Давненько из меня не выходило контента. Пора исправляться. Принёс для тебя дополнение к прошлой статье про объекты.

Я разбирал hidden classes, inline cache и форму объектов. Главный практический совет был простой: если поле опциональное, создай его сразу и положи null, чтобы все объекты сохранили одинаковую форму.

Совет рабочий, но неполный. Форма объекта у V8 может остаться прежней, а контракт поля всё равно изменится. И тогда горячая функция тоже поедет на деоптимизацию.

Если через один путь проходят десятки тысяч однотипных объектов, и ты уже полез смотреть за их формой, стоит понимать и вторую половину механики.

Map знает не только форму

У каждого объекта в V8 есть Map, он же hidden class. Map описывает набор полей, их порядок и смещения. Но в дескрипторе поля хранится ещё и его внутренняя representation, то есть способ, которым V8 ожидает хранить значение.

Упрощённо интересующая нас цепочка выглядит так:

Smi        маленькое целое, закодированное прямо в tagged-слоте
Double     числовое значение с плавающей точкой
HeapObject ссылка на объект в куче: строку, объект, null, undefined и так далее
Tagged     широкое представление, которое принимает и Smi, и ссылки

Это внутренний контракт хранения. В самом V8 отдельно существует ещё и field type, но для перехода из number в string нам достаточно representation.

Когда V8 много раз видит { x: 42 }, поле x может получить representation Smi.

Оптимизатор по известному Map читает поле как маленькое целое и строит код под этот контракт.

Потом кто-то делает так:

obj.x = 'boom'

Строка уже не помещается в Smi. V8 расширяет representation до Tagged, потому что теперь поле должно принимать и целые числа, и ссылки на объекты в куче.

Ключевой момент: это не обязательно создаёт новый Map. Для некоторых расширений V8 обновляет дескриптор на месте, и адрес Map остаётся тем же. Но оптимизированный код зависел не только от адреса Map, а ещё и от representation. Контракт изменился, зависимый код больше нельзя считать безопасным для использования.

Вот сам деопт

Минимальный пример на Node 24.17.0 с V8 13.6:

function readX(object) {
  return object.x
}

const a = { x: 1 }
const b = { x: 2 }

// Убираем отдельную зависимость от constness поля.
a.x = 3
b.x = 4

for (let i = 0; i < 100_000; i++) {
  readX(i & 1 ? a : b)
}

// --allow-natives-syntax
%OptimizeFunctionOnNextCall(readX)
readX(a)

a.x = 'boom'

Запускаем:

node --allow-natives-syntax --trace-deopt demo.js

И получаем:

[marking dependent code ... (readX) for deoptimization,
 reason: dependent field representation changed]

То есть одна запись строки действительно инвалидировала уже оптимизированную readX.

В этой версии V8 %HaveSameMap(a, b) остаётся истинным даже после присваивания строки. Форма та же, Map тот же, а деоптимизация всё равно случилась.

%OptimizeFunctionOnNextCall и %HaveSameMap являются внутренними средствами диагностики V8. В прод их, разумеется, тащить не стоит.

Где здесь подвох с null

Вернёмся к совету «создай поле заранее и положи null».

Для формы объекта он по-прежнему полезен:

const user = { id, name, role: null }

if (isAdmin) {
  user.role = 'admin'
}

Поле role есть у всех объектов с самого начала. Кроме того, и null, и строка относятся к HeapObject, поэтому именно representation при такой записи расширять не требуется.

С числом история другая:

const stats = { score: null } // HeapObject
stats.score = 42              // нужно принять ещё и Smi, получаем Tagged

Если код успел оптимизироваться между этими двумя состояниями, расширение поля может инвалидировать зависимую оптимизацию.

Для целочисленного поля стоит сразу дать целочисленное значение:

const stats = { score: 0 }
stats.score = 42

С undefined та же проблема, что с null: для V8 это объект в куче, а не числовая заглушка.

Но не стоит превращать это в очередной карго-культ. Если null является честным состоянием бизнес-модели, оставь null. Семантика программы важнее одной потенциальной деоптимизации на прогреве.

А если поле хранит дробные числа, одного 0 тоже недостаточно для идеальной стабильности: переход от Smi к Double способен потребовать ещё одно расширение.

Идеальный вариант для горячей структуры: присвоить реальное значение до того, как код станет горячим.

Расширение происходит не на каждом присваивании

Здесь легко сделать неправильный вывод: будто каждое переключение 42 → 'boom' → 42 снова деоптимизирует функцию из-за representation.

Нет. Representation расширяется до Tagged один раз и самостоятельно обратно до Smi уже не сужается. После этого и число, и строка помещаются в установленный контракт. Повторной генерализации поля на каждом переключении нет.

Деопты всё ещё возможны, если горячий код специализировался на фактических значениях. Например, выражение object.x + 1 сначала выполняет числовое сложение, а со строкой начинает конкатенацию.

Это уже другая причина: обратная связь по типам самой операции плюс возможные аллокации строк. Сваливать всё это в одну корзину с field representation удобно только до первого человека, который полезет в --trace-deopt.

Поэтому я не буду продавать здесь красивое «переключение типов замедляет цикл ровно в два раза». Такой микробенч легко измеряет одновременно чтение поля, смену representation, арифметическую специализацию, конкатенацию и повторную оптимизацию. Цифра получится эффектной, но инженерного смысла в ней будет примерно нисколько.

Защищаемый вывод уже есть в трейсе: первое расширение representation способно инвалидировать весь оптимизированный код, который от неё зависит. Цена конкретного деопта зависит от функции, нагрузки, версии V8 и того, сколько зависимого кода придётся пересобрать.

Что делать-то?

Да, в целом ничего :)

Это просто интересные факты про Node.js, так же, как и про Map в прошлой статье.

Но если ты оптимизациофил, то:

• Создавай горячие объекты с полным и стабильным набором полей.
• Для целочисленного поля используй числовое начальное значение, а не null или undefined.
• Присваивай реальное значение до прогрева, особенно если поле может хранить дробные числа.
• Не смешивай число и строку в одном поле без причины.
• Проверяй подозрения через --trace-deopt.

Что в итоге

Одинаковая форма объекта ещё не гарантирует, что оптимизированный код останется валидным. V8 учитывает representation полей и может встроить это знание в машинный код.

Переход number → string дорог не потому, что строка сама по себе медленная. Он опасен в момент, когда ломается контракт уже скомпилированной функции. V8 расширяет поле, помечает зависимый код на деоптимизацию и затем работает с новым, более широким представлением.

А null ни хороший, ни плохой. Для ссылочного поля это нормальная заглушка. Для числового поля это уже другой внутренний контракт.

JS разрешает нам менять типы как угодно. V8 тоже не против. Но лучше не менять.

Кушайте кашу, читайте книги и не меняйте типы без необходимости.

Что почитать

• Fast properties in V8, официальный разбор Maps, дескрипторов и быстрых свойств • Representation в исходниках V8, актуальная внутренняя модель Smi, Double, HeapObject и Tagged • MapUpdater в исходниках V8, генерализация полей и обновление зависимого кода • V8 internals: hidden classes & inline caches, подробный разбор Mathias Bynens

_Hidden classes, inline cache и почему shape объекта важнее, чем кажется._

Продолжу про микро-оптимизаций. После Date.now() и parseInt/parseFloat — про, казалось бы, самую безобидную вещь: обычный {}.

Сразу оговорка: для 99% систем это не имеет значения. А вот если у тебя hot path, через который проходят десятки тысяч объектов в секунду, или ты пишешь библиотечный код, стоит знать, что V8 на самом деле делает с твоими объектами.

И чего он там с ними делает?

Когда ты создаёшь объект, V8 не выделяет «мешок ключей». Он строит для него hidden class (_map_ внутри V8) структуру, которая описывает layout: какие у объекта поля, в каком порядке они лежат, какого типа, по каким офсетам читать. Сам объект это компактный массив значений, как struct в C. Hidden class хранится отдельно, и каждый объект держит на него ссылку.

Hidden classes связаны между собой через transitions и вместе образуют transition tree. Когда ты добавляешь поле к объекту, V8 идёт по исходящему переходу из текущего hidden class: если переход с таким полем уже есть переключается на существующий дочерний, если нет создаёт новый hidden class и новую ветку дерева.

Если несколько объектов идут по одним и тем же переходам в одинаковом порядке они разделяют один hidden class. Это даёт V8 базу для inline cache: «по этому офсету всегда лежит string, читаем напрямую, без проверок».

Когда hidden classes начинают расходиться (по порядку, по типам, по добавлению/удалению), inline cache переходит: – monomorphic (один shape — fast path), – polymorphic (до 4 shapes — V8 проверяет каждый, всё ещё быстро), – megamorphic (4+ — V8 сдаётся, идёт через generic lookup).

Стоимость растёт на каждом шаге.

Где ты теряешь?

Классический пример постепенная сборка vs литерал:

const a = {}
a.id = 1
a.name = 'jopa'

const b = { id: 1, name: 'jopa' }

Если порядок добавления полей совпадает, оба варианта в итоге попадают на один hidden class. У литерала есть бонус V8 запоминает финальный shape как boilerplate и при повторных вызовах аллоцирует объект сразу с готовым layout, без прохода по transition tree. Но в hot loop разница в установившемся режиме копеечная.

Хуже, если порядок полей в разных фабриках не совпадает:

function makeA(id, name) { return { id, name } }
function makeB(name, id) { return { name, id } }

Это уже два разных hidden class. Любой код, который читает obj.id через эти фабрики, видит два shape на одном call site и IC становится polymorphic. Само по себе ещё не больно, но если таких разных объектов не два, а шесть, то добро пожаловать в megamorphic.

Ещё кейс условное добавление полей:

const user = { id, name }

if (isAdmin) {
  user.role = 'admin'
}

Часть объектов имеет shape {id, name}, часть — {id, name, role}. Уже polymorphic. Лучше класть role: null сразу и потом присвоить значение при необходимости.

delete — отдельная история

delete user.name

Вот тут V8 уже не прощает. delete переводит объект в dictionary mode (он же slow mode, normalized properties). Это hashmap вместо фиксированного layout. Ни inline cache, ни офсетов, каждое чтение поля идёт через hash lookup в C++ runtime. И обратно V8 объект уже не вернёт, даже если форма стабилизировалась.

Вроде как память освободил. А по факту превратил объект в Map без типизации.

Если поле больше не нужно лучше присвой null или undefined. Shape сохранится, движок не потеряет в оптимизации.

А что по цифрам?

Стенд: Node 24, миллион объектов с тремя полями, в hot loop читаем obj.id, меряем ns/op. По три прогона, чтобы JIT успел устаканиться.

— literal (same shape): 3.99 нс — stepwise (same order): 4.08 нс — poly IC (2 shape): 4.65 нс — megamorphic (6 shapes): 8.51 нс — dict mode (after delete): 56.12 нс

Что видно: – literal vs stepwise — разницы практически нет. V8 одинаково хорошо справляется с обоими. – polymorphic IC (2 shape) — ~15% оверхед. V8 спокойно тянет до 4 shape на одном call site. – megamorphic (6 shape) — x2+ к чтению. Уже серьёзно. – delete (dictionary mode) — x14 медленнее. Больно :)

На 100k RPS × 50 чтений полей на запрос с dict-mode объектами вместо нормальных — потеря ~260 мс CPU/с.

А что было на Node 22?

Для наглядности — те же сценарии на Node 22:

— literal: 11.0 → 4.0 нс (x2.8) — stepwise: 11.1 → 4.1 нс (x2.7) — poly (2 shape): 10.3 → 4.7 нс (x2.2) — megamorphic: 14.1 → 8.5 нс (x1.7) — dict mode: 56.8 → 56.1 нс (=)

Что интересно:

– Fast path между релизами стал ~x2.5 быстрее. TurboFan и Maglev продолжают тюниться, монохромное чтение поля на Node 24 — 4 нс против 11 на Node 22. – Dict mode — константа. 56 нс на обеих версиях. Это C++ hashmap lookup, JIT там не играет, оптимизировать нечего. – Относительная разница fast/slow растёт. На Node 22 delete был x5 медленнее literal'а, на Node 24 — уже x14. Fast path уходит вперёд, slow path стоит.

Вывод: с каждым новым V8 сидеть в dictionary mode или megamorphic IC становится всё дороже _относительно_ правильного кода.

А что делать то?

– В hot path — литералы, со всеми полями сразу. Не знаешь значение полож null. – Поля во всех фабриках — в одном порядке. Делаешь { id, name }, делай везде { id, name }. – delete — не нужон. Только obj.field = null (или undefined). – Если объект сложный и часто создаётся — класс или фабрика. Один shape гарантированно. – Не стоит превращать один call site в универсальную точку на все случаи жизни: четыре shape потолок V8, дальше generic.

Что в итоге?

Объект в JS не «просто словарь». Это контракт с V8: ты обещаешь стабильный shape, V8 обещает быструю работу через hidden classes и inline cache. Нарушаешь — съезжаешь в polymorphic, потом megamorphic, потом dictionary mode. С каждым шагом дороже.

В обычном CRUD это не заметно. На hot path — это десятки процентов CPU и заметные хвосты по p99.

Date.now() тратил CPU на syscall, parseFloat — на парсинг, плохой shape — на cache miss. А потом говорят: "ой да ну какой Node, он же медленный, давайте напишем на Go и пойдем за ванильным лате на растительном"

Node быстрый. Просто не мешай ему.

Что еще почитать? – V8 internals: hidden classes & inline caches — Mathias Bynens, must-read – Fast properties in V8 — официальный блог V8 – Elements kinds in V8 — про массивы и их shapes

Всё хорошее и плохое имеет свойство заканчиваться, и я спешу тебя порадовать: мы с тобой добрались до финальной части серии про System Design. Путь был сложный, много буков было написано. Я последовательно попытался донести ключевые моменты о процессе проектирования архитектуры.

Надеюсь, сейчас ты уже понимаешь, что архитектура — это далеко не просто красивая схема. Это длительный и сложный итеративный процесс сбора требований. Это глубокий анализ и понимание потоков данных. Это кропотливое планирование обратной связи. И, наконец, это трезвый выбор инструментов без погони за «стандартом индустрии». Всё это вместе помогает создать архитектуру, способную выжить в проде.

Примерно на этом этапе принципиальная схема с детализацией для разных команд и специалистов готова, ТЗ написано, спецификации составлены, и таргеты определены. Команды окончательно определились с инструментами и подходами к реализации, начинают писать код и собирать инфру.

Казалось бы, всё, конец. Можно спокойно выдохнуть, дождаться альфы, посмотреть, как это всё будет дышать в приближённой к реальности среде.

Но нет. К сожалению, а может, и счастью, это далеко не конец. А почему? С какого?

У самурая есть только путь

И у архитектуры тоже. Тот момент, когда код написан, а инфраструктура поднята, далеко не финишная черта. Это лишь первый серьёзный контрольный пункт на бесконечной трассе. Потому что живая система не может быть статичной. Она дышит, меняется, сталкивается с реальностью.

Ты помнишь три столпа: надёжность, масштабируемость и сопровождаемость? Так вот, прод — это полигон, где они вступают в жестокую схватку. Твоя архитектурная схема превращается в реальность, и эта реальность начинает ставить эксперименты:

Теория потоков данных сталкивается с практикой. Ты разделил read-path, write-path и обработку. Отлично. Но теперь метрики показывают, что твой "изолированный" контур обработки в фоне неожиданно конкурирует за дисковый IO с репликацией базы в пиковое время. Поток данных оказался хитрее твоей схемы. Значит, надо корректировать: менять расписание, добавлять лимиты, пересматривать приоритеты.

Обратная связь проходит боевое крещение. Ты настроил Circuit Breaker и backpressure. А они срабатывают слишком часто или, наоборот, молчат, когда уже всё прилегло. Приходится калибровать пороги по живому трафику. Твои "управляемая деградация" и "предсказуемый отказ" из красивых слов превращаются в конкретные скрипты, алерты и рутину эксплуатации.

Выбор инструментов проверяется на прочность. Ты не поддался и взял «скучный» PostgreSQL. Он отлично держит. Но оказалось, что одна конкретная аналитическая выборка, о которой забыли спросить на старте, выполняется 20 секунд. Придётся думать: то ли денормализовать, то ли параллелить, то ли подружить его с тем самым ClickHouse, против которого ты выступал.

Компромиссы перестают быть абстрактными. Ты решил пожертвовать строгой консистентностью ради скорости. И вот первый пользователь пишет в саппорт: "Я только что лайкнул пост, а счётчик не обновился!". Бизнес задаёт вопрос: "Это баг или фича?". Тебе приходится объяснять, что это не баг, а осознанный выбор, и договариваться, как сделать эту "фичу" менее болезненной для пользователя.

Это и есть тот самый путь. Архитектура — это не проект, который можно сдать. Это состояние системы и процесса вокруг неё.

Финал? Нет, передача эстафеты

Когда первая версия системы уезжает в прод, твоя роль как проектировщика не заканчивается. Она трансформируется. Теперь ты не столько архитектор-созидатель, сколько архитектор-исследователь и наставник.

Ты передаёшь эстафету командам эксплуатации (SRE/DevOps) и разработки, снабжая их не просто схемой, а моделью мышления:

Карта рисков и слабых мест — показываешь, где система может хрустнуть, и как это заметить по метрикам.

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

Принципы эволюции — объясняешь, почему нельзя "быстро прикрутить" новую фичу, нарушающую разделение потоков данных, и как это сделать правильно.

А сам возвращаешься к началу цикла. К анализу метрик, к новым требованиям бизнеса, к проектированию следующих итераций. Потому что система, которая не эволюционирует, — мёртвая система.

Так что же, всё напрасно? Вечный цикл «нарисовали-сломали-перерисовали»? Никакого конца?

Как раз наоборот! Вся проделанная работа — сбор требований, осознание компромиссов, проектирование потоков и обратной связи, трезвый выбор инструментов — это и есть тот самый фундамент, карта и компас. Ты не построил неприступную крепость на века. Ты построил живой, адаптивный организм и дал команде инструменты для его развития.

Фундамент — потому что без этой работы система рухнет при первом же столкновении с реальностью. Карта — потому что теперь ты видишь не просто квадратики, а ландшафт, где текут данные и как система на них реагирует. Компас — потому что когда появляются новые требования или всё идёт не по плану, у тебя есть принципы (те самые три столпа) и понимание потоков, чтобы принимать решения, а не тыкать пальцем в небо.

Что в итоге?

Ты прошёл полный цикл взрослого System Design:

1. Перестал рисовать квадратики и понял, что дизайн — это борьба с реальностью.
2. Научился задавать неудобные вопросы, чтобы превращать влажные фантазии бизнеса в измеримые требования.
3. Осознал три столпа: надёжность, масштабируемость, сопровождаемость — и начал жонглировать их противоречиями.
4. Увидел систему как потоки данных и разделил их на контуры записи, чтения и обработки.
5. Научил систему реагировать на мир с помощью обратной связи: backpressure, circuit breakers и управляемой деградации.
6. Осознанно выбрал инструменты, не поддавшись искушению забивать гвозди микроскопом.

И вот теперь ты здесь. Понимаешь, что конечной точки нет. Есть только путь постоянной адаптации, рефакторинга и осознанных компромиссов. И в этом — вся красота и сложность.

Главное — не бояться начинать, мыслить структурно и помнить, что лучшая архитектура та, что позволяет системе и команде меняться не ломаясь. А путь, как известно, и есть главная цель.

Спасибо, что прошёл этот путь со мной. Удачи в проектировании систем, которые не просто работают, а живут и растут.

Я не прощаюсь, совсем скоро вернусь и принесу почитать что-нибудь интересное.

Что ещё почитать для пути:

· Книга «Designing Data-Intensive Applications» Мартина Клеппмана — библия по теме. · Блог High Scalability — разборы архитектур реальных компаний. · Книга «Release It!» Майкла Найгарда — про то, как проектировать системы, которые не падают в проде. · Technology Radar от ThoughtWorks — чтобы держать руку на пульсе, но не гнаться за каждой волной.

Надеюсь ты, читатель, выжил и с пользой провёл этот новогодний фриз. Тонны салатов, вкусной еды и тотального разложения продуктивности не смогли сломить твою тягу к знаниям и развитию.

С учётом пройденного пути кажется, что всё готово. Требования выбиты, потоки данных распутаны, компромиссы между надёжностью, масштабируемостью и сопровождаемостью найдены, обратная связь продумана. В голове — стройная архитектурная концепция. Пора бы уже и код писать.

Вот он, тот самый момент, которого все мы так ждали. Выбор инструментов. Тех самых квадратиков, которые ты будешь рисовать на схеме.

Рука так и тянется к модному, к «стандартам индустрии». Хочется взять Kafka, потому что «все большие так делают». Запустить десяток микросервисов на Go. Запихнуть всё в Kubernetes и поставить сверху service mesh. А базу, конечно, ту самую очередную Distributed SQL, про которую читал на Хабре.

Астанавись. Выбор инструментов это не награда за проделанную работу. Это не «финальный босс», которого нужно победить эпической убервафлей. Это ещё одна серия компромиссов, где твоим главным врагом становится хайп, а союзником скучный, нудный документ с требованиями.

Почему «просто взять лучшее» не работает?

Потому что у каждого инструмента есть своя цена. И речь не только о лицензии.

_Цена обучения._ Команда знает PostgreSQL как свои пять пальцев, но ты хочешь CockroachDB для глобального шардинга. Готовы ли всё на месяцы замедлиться, изучая новые паттерны, отладку и тонкости?

_Цена эксплуатации._ Этот блестящий распределённый кеш самовосстанавливаться при отказе двух узлов? Здорово. А кто будет его мониторить, настраивать и разбираться, почему он вдруг начал терять 1% записей? Это твои SRE? Они уже согласны?

_Цена связности._ Каждый новый «квадратик» не просто функция. Это новая точка отказа, новый протокол, новый клиент в коде, новый драйвер, новый источник задержек в сетевых вызовах. Микросервис на Rust может быть быстрым, но если для связи с ним всем остальным сервисам нужна кастомная бинарная сериализация, ты добавляешь сложность во всю систему.

_Цена моды._ Инструмент, о котором все кричат сегодня, завтра может оказаться «legacy-технологией, от которой все уходят». Выбирая его, ты берёшь на себя обязательство по его миграции через N лет.

Так, как же выбирать то?

Отталкивайся не от хайпа, а от следствия.

Твоя отправная точка не список «крутых технологий», смотри на:

_Требования из твоего документа._ Нужна строгая консистентность? Забудь про eventual consistency stores для записи ядра. Нужны джойны сложных агрегатов? Привет, реляционные базы или тщательно спроектированные документные.

_Характеристики потоков данных._ Данные пишутся редко, а читаются всегда? Кеш, или read-реплики. Нужна гарантированная доставка событий между контурами? Пора смотреть на брокеры (прости господи). Но не «воткнём Кафку», а «нам нужен персистентный лог с консьюмер-группами».

_Выбранные компромиссы._ Пожертвовали скоростью записи ради надёжности? Инструмент должен давать сильные гарантии durability. Пожертвовали консистентностью ради масштабируемости? Ищите базу с tuneable consistency.

Пример: Выбираем хранилище для «ленты как у Threads».

Из требований помнишь: скорость чтения критична, актуальность лайков/комментариев может отставать на 5 секунд, рост медленный.

_Искушение:_ Взять Cassandra или ScyllaDB. Горизонтальное масштабирование, высокая доступность, запись быстрая. Вайбово, надо брать!

Реальность:  Модель данных: лента для каждого пользователя, которая часто пересчитывается. Это запросы по ключу (user_id) с range scan по времени. Cassandra неэффективна для range scans в рамках одного партишна. А денормализовать ленту для каждого подписчика это гигантский объём данных при малом росте.

Скучное решение:  PostgreSQL с таблицей feeds (user_id, post_id, timestamp), правильными индексами и репликой для чтения. На старте выдержит легко. Команда знает. При росте сначала тюнинг, потом партициирование, и только потом, возможно, шардинг. Инструмент соответствует реальным, а не гипотетическим потокам данных.

Критерии выбора: чек-лист перед тем, как «воткнуть»

1. Решает ли он КОНКРЕТНУЮ проблему из моего дизайна? Не «как бы нам использовать Redis», а «нам нужно хранить сессию пользователя с TTL 15 минут».
2. Соответствует ли он «бюджету боли» по сопровождению? Есть ли в команде экспертиза? Есть ли готовые Terraform-модули, Helm-чарты, дашборды в Grafana?
3. Что происходит при его отказе? Это SPOF? Как он интегрируется в нашу обратную связь (circuit breakers, fallbacks)?
4. Как он себя ведёт в наших паттернах доступа? Под нагрузкой, в наших хвостах распределения (p99, p999)?
5. Насколько он нас загоняет в угол? Легко ли будет заменить его через год, если требования изменятся кардинально?

Что в итоге?

_Сначала_: принципиальное решение (например, «нам нужен персистентный лог событий»). _Потом_: варианты (Kafka, NATS JetStream, Pulsar, RabbitMQ с quorum queues). _Затем_: проверка по чек-листу против ТВОИХ требований и контекста (нагрузка, экспертиза, инфраструктура). _В финале_: конкретный инструмент.

Правильно выбранный инструмент тот, что тихо растворяется в архитектуре, позволяя системе работать так, как ты задумал. Не тот, что требует к себе постоянного внимания и героических усилий.

Архитектура рождается из требований и компромиссов, а не из списка технологий. Инструмент это всего лишь наиболее точная реализация твоего решения на данном этапе. Лучше взять простое и знакомое решение. Это лучше, чем выбирать модное без понимания, зачем.

А что дальше? Дальше код, деплой, метрики и... встреча с суровой реальностью. А почему это ещё не конец, я расскажу в следующий раз.

Читайте книги, пишите код, кушайте кашу.

Что ещё почитать:

• Database of Databases — поможет с выбором бд
• Martin Fowler — Technology Radar — хороший источник для размышлений о зрелости технологий.
• 4. System design. Обратная связь. Если бы мы знали, что это такое, но мы не знаем, что это такое

В прошлый раз я говорил про потоки данных. Про то, как данные движутся по системе, про контуры записи, чтения и обработки. Про то, что архитектура должна строиться вокруг движения данных, а не вокруг технологий, трендовых инструментов и “стандартов индустрии”.

Так вот, есть один момент, который я тогда только упомянул вскользь, а он на самом деле очень важный. Поток данных может выйти из-под контроля. Может прийти больше, чем система способна переварить. Может появиться всплеск нагрузки, который сломает всё к чертям. Может упасть внешняя зависимость, и система начнёт помирать, пытаясь дождаться ответа, которого никогда не будет.

В такие моменты система должна как-то реагировать. Непросто падать с ошибкой 503 и отправлять всех в jopa. А делать что-то умное. Что-то, что позволит ей выжить, пусть и в урезанном виде.

На помощь нам придёт “обратная связь”. Если бы мы знали, что это такое, но мы не знаем, что это такое. Шутка, конечно. На самом деле знаем, но не помним. Штука очень полезная, про неё забывают на этапе проектирования и потом напихивают в разные места, затыкая дыры. Не надо так.

Что же такое обратная связь?

Обратная связь это когда система реагирует на изменения в окружающей среде и корректирует своё поведение. Звучит просто. И на практике просто, если знать, что делать. Если не знать - сложно. Такая простая штука может значительно влиять на жизнеспособность системы. Без неё система работает ровно до первого неожиданного события, а потом падает и всё: стресс, убытки, всё лежит, все грустят.

Представь термостат. Он измеряет температуру и включает или выключает обогрев, чтобы поддерживать заданную температуру. Это классический пример обратной связи: система реагирует на изменения и корректирует своё поведение. Без этого механизма температура либо постоянно росла бы, либо падала, пока всё не сломалось. В программных системах то же самое. Только вместо температуры у нас нагрузка, задержки, ошибки, доступность ресурсов. И система должна уметь реагировать на эти изменения.

Без обратной связи система становится хрупкой. Она работает ровно до тех пор, пока всё идёт по плану. Как только появляется что-то неожиданное пик нагрузки, сбой компонента, изменение требований система ложится. Потому что у неё нет механизма, который бы сказал: “Оу-оу, полегче, я такое не умею, я такое не могу и вообще мне тяжко”. По-хорошему нужно систему научить на такое реагировать. Для этого нужно как минимум понимать потоки данных в системе.

Есть несколько типов обратной связи:

Отрицательная обратная связь это когда система компенсирует отклонения и возвращает состояние к норме. Это стабилизация. Rate limit, который замедляет запросы при перегрузке. Circuit breaker, который отключает неработающий сервис, чтобы не тратить ресурсы впустую. Кеш, который отдаёт устаревшие данные, когда свежие недоступны. Всё это примеры отрицательной обратной связи: система реагирует на проблему и пытается вернуть всё в рабочее состояние. Это то, что тебе нужно в 99% случаев.

Положительная обратная связь это когда система усиливает отклонения. Звучит опасненько. Каскадные падения сервисов, когда один упал, нагрузка перераспределилась, другие не выдержали и тоже упали. Runaway-процессы, которые жрут всё больше ресурсов, пока система не умрёт. Но иногда положительная обратная связь нужна: например, когда система должна быстро масштабироваться при росте нагрузки. Главное контролировать этот процесс.

Backpressure это сигнал “стоп, хватит”. Когда вход растёт быстрее, чем система может переварить, она должна как-то сообщить источнику: “Полегче, я не успеваю”. Это может быть явный отказ в обработке, замедление ответов или очередь, прости господи, которая переполняется и начинает отклонять новые задачи.

Управляемая деградация это когда система жертвует частью функциональности, но остаётся работоспособной. Вместо того чтобы упасть целиком, система отключает несущественные фичи, упрощает обработку, отдаёт менее свежие данные. Ядро системы продолжает работать и предоставлять основной функционал. Это не идеальное решение, но лучше, чем полный отказ. Пользователи могут не увидеть свежие рекомендации или точную статистику, но смогут прочитать ленту и создать пост, например.

Все эти механизмы работают вместе, дополняя друг друга, создавая систему, которая может адаптироваться к изменениям. Backpressure защищает от перегрузки, управляемая деградация позволяет продолжать работать при проблемах, отрицательная обратная связь стабилизирует систему, положительная (когда нужна) позволяет быстро масштабироваться.

Где обратная связь нужна в архитектуре?

Обратная связь должна быть на всех уровнях системы. Не только в одном месте, но и везде, где система взаимодействует с внешним миром или внутренними компонентами. Классическая ошибка: добавили rate limit на входе и радуемся, что всё готово. А потом система падает из-за проблем с чтением или фоновыми задачами. “Как так? Я же защитил вход!”, ага, да, но не учёл весь поток данных.

На уровне контура записи обратная связь защищает систему от перегрузки. Rate limit ограничивает количество запросов в единицу времени. Throttling замедляет обработку, когда система перегружена. Валидация отклоняет некорректные данные до того, как они попадут в систему и начнут создавать проблемы. Без этого контур записи может стать точкой отказа: слишком много данных, система не справляется, все грустят. Классическая история: кто-то решил загрузить миллион записей через API, система пытается всё обработать, база задыхается, всё падает, DDoS. А могло бы быть просто: 429 “Слишком много запросов, попробуйте позже”.

На уровне контура чтения обратная связь обеспечивает доступность данных даже при проблемах. Кеширование позволяет отдавать данные быстро, даже если источник медленный. Fallback на устаревшие данные даёт возможность показать что-то пользователю, когда свежие данные недоступны. Read replicas распределяют нагрузку чтения, не перегружая основную базу. Без этого каждое чтение становится зависимостью от работоспособности всех компонентов, и любая проблема превращается в полный отказ. Например, система, где каждое чтение идёт в основную базу: когда база тормозит, всё падает периодически, и юзер видит йух. А могло бы быть: читаем из реплики, если реплика недоступна из кеша, если кеш пустой из основной базы, но с таймаутом. И система продолжает работать. Да, кода раза в два больше, зато надёжненько.

На уровне контура обработки обратная связь управляет приоритетами и ресурсами. Приоритизация задач позволяет обрабатывать важное в первую очередь, откладывая менее критичное. Отмена долгих операций освобождает ресурсы, когда система перегружена. Изоляция фоновых задач не даёт им мешать пользовательским запросам. Без контроля тяжёлые операции могут заблокировать всю систему, и пользователи перестанут получать ответы. Классика: фоновый джоб по пересчёту статистики запустился в пик нагрузки, сожрал CPU и память, юзеры получают отказ в обслуживании, система прилегла. А могло бы быть так: фоновые задачи останавливаются при высокой нагрузке, возобновляются, когда нагрузка спадает.

На уровне инфраструктуры обратная связь обеспечивает масштабирование и отказоустойчивость. Автоскейлинг добавляет ресурсы при росте нагрузки и убирает при снижении. Circuit breakers отключают неработающие зависимости, чтобы они не тянули систему вниз. Health checks обнаруживают проблемы до того, как они станут критичными. Это позволяет системе адаптироваться, реагировать на сбои и нагрузку. Например, система курильщика, где при падении одного сервиса все остальные продолжают пытаться его вызвать, накапливают таймауты, система деградирует. А в системе здорового человека: circuit breaker глушит упавший сервис, система продолжает работать без этого сервиса, периодически проверяет, не восстановился ли он.

Важно понимать: обратная связь на одном уровне не решает проблему полностью. Нужна система обратных связей, которая работает на всех уровнях одновременно. Иначе получится ситуация, когда ты защитил вход, но система падает из-за проблем с чтением. Или наоборот. Rate limit на входе бесполезен, если чтение из базы блокирует всю систему. Кеширование не поможет, если фоновые задачи жрут все ресурсы. Circuit breaker не спасёт, если проблема внутри, а не во внешних зависимостях.

Поэтому проектировать обратную связь нужно системно. Не “добавим rate limit и всё”, а “посмотрим, где система может сломаться, как идут потоки данных, выявим уязвимые места и добавим обратную связь там, где нужно”. Это требует понимания потоков данных, о которых мы говорили в прошлый раз. Ты можешь добавить обратную связь везде, но это будет оверинжиниринг. Или можешь добавить только в одном месте, но этого будет недостаточно. Нужно найти баланс.

Пример

Давай посмотрим, как это работает на практике. Представь бота, который торгует на нескольких криптобиржах одновременно: Binance, OKX, Bybit. Нормальное состояние: WebSocket-потоки идут стабильно, ордера исполняются, задержки в пределах нормы. Но вот происходит что-то: новость про регуляцию, Трамп что-то сказал, или Хейс чихнул, или все вдруг решили поторговать. Классическая ситуация: всё было хорошо и вдруг всё плохо. Наверное, ты даже где-то такое видел?

Без обратной связи система пытается обработать всё. Каждое обновление из WS обрабатывается, каждый тик анализируется, каждый ордер отправляется на биржу. Потоки начинают душить систему, очередь сообщений растёт, задержки увеличиваются с миллисекунд до секунд. Система начинает принимать плохие решения, потому что цены меняются быстрее, чем система успевает на них реагировать. А потом система вообще ложится. Какой-то сервис положил, допустим, базу или распределённый кеш, откуда читает контур принятия решений. В тг к тебе уже стучатся: “Бот лёг? Там движение! Ордеров нет!” А ты в душе не представляешь, почему оно там лежит и что вообще происходит.

Теперь добавим обратную связь на разных уровнях.

На контуре записи (WS-потоки) ставим backpressure. Когда система не успевает обрабатывать обновления из WebSocket, она сигнализирует: “Падажди, я не успеваю”. Это может быть явный отказ принимать новые сообщения или замедление обработки. Но важно не переборщить: слишком агрессивный backpressure заставит тебя пропустить важные обновления цены, слишком мягкий не поможет при реальном всплеске. Нужно найти золотую середину. Стоит начать с консервативных значений и вручную, по метрикам, подгонять при необходимости.

На контуре чтения (обработка котировок) включаем приоритизацию. Критичные пары BTC/USDT, ETH/USDT обрабатываются в первую очередь, менее ликвидные потом. Если система перегружена, она может временно отключить обработку некоторых пар, сосредоточившись на самых важных. Это лучше, чем пытаться обработать всё и упасть.

На контуре обработки (торговая логика) приоритизируем ордера. Критичные ордера те, что должны исполниться немедленно, например, обрабатываются в первую очередь. Менее критичные ордера откладываются, когда система перегружена. Если нагрузка критическая, система может временно отключить некоторые стратегии, освобождая ресурсы для самых важных.

Для внешних зависимостей бирж, API-провайдеров, ораклов организуем circuit breakers. Если биржа не отвечает или отвечает слишком медленно, circuit breaker “разрывает цепь” и перестаёт отправлять ордера на эту биржу на некоторое время. Система продолжает торговать на других биржах, но не падает из-за проблем с одной биржей. Пример ошибки: бот отправляет ордер на Binance, тот не отвечает (rate limit или просто проблемы с сетью), бот ждёт таймаут, накапливает ордера, падает. А могло бы быть: circuit breaker разрывает цепь, бот продолжает работать на других биржах, периодически проверяет, не восстановился ли Binance.

Всё это вместе создаёт систему, которая может деградировать управляемо. При всплеске волатильности она не падает, а упрощается: обрабатывает только критичные пары, отключает менее важные стратегии, перестаёт торговать на проблемных биржах. Система может заработать меньше, но не потеряет всё из-за полного отказа.

Попробую на цифрах показать. Допустим, обычная нагрузка: 10 тысяч обновлений в секунду от всех бирж. Система справляется, все обновления обрабатываются за 10–50 миллисекунд. Внезапно приходит 50 тысяч обновлений в секунду: дамп, все начинают торговать одновременно, биржи заливают обновлениями. Без обратной связи очередь сообщений растёт, задержки увеличиваются до секунд, система начинает терять деньги, потому что цены меняются быстрее, чем система успевает на них реагировать. А потом система вообще падает.

С обратной связью картина другая. Backpressure на WS-потоках пропускает только 20 тысяч обновлений в секунду, остальные отбрасываются. Из этих 20 тысяч система обрабатывает только критичные пары: BTC/USDT, ETH/USDT; остальные временно игнорируются. Circuit breaker отслеживает задержки на биржах: если задержка превышает допустимый порог (допустим, 500 миллисекунд), он перестаёт отправлять ордера на эту биржу. Менее критичные стратегии останавливаются, освобождая CPU и память для самых важных.

Результат: система продолжает работать. Часть пар не обрабатывается, часть стратегий отключена, но ядро системы стабильно. Система может заработать меньше, но не потеряет всё из-за полного отказа. Когда волатильность спадает, всё возвращается в норму: circuit breaker возвращает в работу биржи, стратегии возобновляются, обработка всех пар восстанавливается.

Важно понимать: это неидеальное решение. Идеального не бывает. Но это управляемая деградация вместо полного отказа. С точки зрения пользователя падение прибыли значительно лучше, чем полный слив.

Приведу несколько типичных ошибок.

Типичная ошибка, игнорирование обратной связи вообще. “У нас же монга с кафкой, они всё выдержат”. Нет, не выдержат. Рано или поздно нагрузка превысит возможности, и система упадёт. Обратная связь не опциональная фича для highload-систем. Это необходимость для любой системы, которая хочет выжить.

Другая ошибка, неправильная настройка. Rate limit на 1000 запросов в секунду, когда система реально может обработать только 100. Или circuit breaker, который срабатывает после одной ошибки и блокирует сервис на час. Или кеш с TTL в секунду, который не даёт никакого эффекта. Обратная связь должна быть настроена под реальные возможности системы и требования бизнеса. Иначе она либо не поможет, либо навредит.

Третья ошибка, отсутствие мониторинга. Если ты не видишь, когда и как срабатывает обратная связь, ты не можешь понять, работает ли она правильно. Сколько запросов отклоняется rate limiterом? Как часто circuit breaker банит ресурс? Насколько часто пользователи видят устаревшие данные из кеша? Какой вообще hit rate по кешу? Без метрик обратная связь становится чёрным ящиком, и ты не знаешь, помогает она или мешает.

Четвёртая ошибка, обратная связь только на одном уровне. Защитил вход rate limiterом, но забыл про чтение. Или настроил кеширование, но не подумал про фоновые задачи. Система всё равно падает, просто в другом месте. Нужна комплексная система обратных связей, которая покрывает все уровни архитектуры.

Что в итоге?

Обратная связь очень полезная и нужная штука. Это практический механизм, без которого система не может адаптироваться к изменениям и выживать.

Без обратной связи система работает ровно до первого неожиданного события: пик нагрузки, сбой компонента, изменение требований и всё ломается. С обратной связью система может реагировать, адаптироваться, деградировать управляемо, но продолжать работать.

Мы уже прошли путь от сбора требований через понимание компромиссов и потоков данных к обратной связи. Это логичная последовательность: сначала понимаешь, что нужно системе, потом выбираешь компромиссы, потом видишь, как данные движутся, и, наконец, настраиваешь реакцию системы на изменения.

Обратная связь связывает всё вместе. Она превращает статичную схему в живую систему, которая может реагировать на реальность. Без неё даже самая красивая архитектура останется просто набором компонентов, которые красиво выглядят на диаграмме, но не работают в проде.

Поэтому когда проектируешь систему, думай не только про компоненты и связи между ними. Думай про то, как система будет реагировать, когда что-то пойдёт не так. Потому что что-то обязательно пойдёт не так. И лучше быть к этому готовым.

Простая система с правильной обратной связью лучше сложной системы без неё. Потому что первая продолжит работать, когда вторая упадёт.

И в этом вся суть system design: не нарисовать красивую схему, а построить систему, которая выживет.

Увидимся в Новом году. Кушайте салатики и читайте книги. Хейтеры, люблю вас!

Что ещё почитать:

• 0. System design – это тебе не квадратики рисовать
• 3. System design. Потоки …, гхм, данных - предыдущая статья про потоки
• Release It! Майкл Найгард про проектирование production-ready систем
• The Circuit Breaker Pattern Фаулер про circuit breakers

_Штош. Тут должен быть мем с котом, но его не будет. Немного выбило меня из ритма повествования. Можно меня поздравить, я теперь совсем безработный, буду чилить и возможно даже больше писать "умных мюслей". А может, и не буду, а может, завтра уже буду работать в новом месте, а может, и нет. Посмотримс_

Ну ладно, минутка офтопа закончилась. Вернёмся к system design.

В прошлый раз я закончил статью анонсом большого практического материала. Хотел на практике показать, как получается архитектура на основании собранных требований. Материал написал, получилось много, сложно и как-то скомкано. Не получилось впихнуть невпихуемое в рамки одной статьи. Поэтому переобуваюсь в прыжке и предлагаю тебе продолжить знакомится с важными элементами system design.

На этот раз расскажу тебе про "Потоки данных", зачем стоит заранее подумать, куда и как текут данные, почему это знание значительно увеличит шансы на выживание проекта, и как не получить _потоки говны_ вместо данных.

Что за потоки и откуда и куда текут?

Есть одна особенность, которую я замечаю у разработчиков, у тех, кто хочет попробовать в архитектуру. Они все думают о системе как о наборе компонентов. Сервис А общается с Сервисом Б. Коллекция users связана с коллекцией balances. Тут мы очередь вкрячим, тут кеш бросим, и мониторинг сверху прикрутим, и чтоб графики красивые. Получается схема, которую можно показать коллегам и сказать: "_Смотрите, у меня современная, красивая архитектура!_"

Проблема в том, что такая схема не отражает жизнь системы. Она статична. Её можно повесить на стену, но она ничего не скажет о том, почему система начинает деградировать, где начинается нагрузка и что именно может сломаться.

Все забывают, что единственная настоящая работа системы, это преобразование данных из одного состояния в другое. Нет данных, нет и системы. И данные, в отличие от компонента на диаграмме, не стоят на месте. Их может быть много или мало, но в любом случае они как-то попадают в систему, движутся внутри неё, где-то оседают и в какой-то момент исчезают.

Это непрерывный поток. Можно сравнить с рекой или ручьём. В одном месте тихое спокойное течение, в другом месте пороги, стремительный бурный поток и водовороты, где-то разливы, а иногда это всё может превратиться в говнотечь, если вовремя не подумать о берегах.

Поэтому, когда я говорю "потоки данных", я вообще не говорю про Kafka streams, SSE, event sourcing или очередной модный паттерн. Я говорю про базовую механику системы. О том, что данные всегда в движении. И что именно это движение диктует архитектуру куда сильнее, чем выбранная база, фреймворк или микросервисная топология.

По опыту, большинство архитектурных ошибок появляются не из-за того, что выбрали «не ту БД» или «не тот язык». Ошибки появляются из-за того, что никто не задался вопросом: куда эти данные идут и что с ними происходит по пути.

Вот делаешь ты API, которое принимает пост. А дальше что? Он превращается в одну запись? В несколько? Нужно ли рассылать дальше? А подтверждение нужно? Кешировать до преобразования или после? Кто читает? Как часто? Как долго данные остаются актуальными? Как они валидируются?

На большую часть вопросов отвечают требования, для этого ты их и собирал. Важно формализовать поток. Но если ты не можешь ответить на эти вопросы, дальше нет смысла рисовать красивые куберы, очереди (прости господи), базы и реплики. Сколько ни старайся, данные всё равно потекут так, как им положено по природе процесса, а не по твоей диаграмме.

Важно понимать, что данные это не сущности. Данные это движение сущностей.

Пост, пользователь, лайк это не просто строка в таблице или документ в коллекции. Это срез конкретного состояния. Поток данных это не про срез. Это про историю изменений. Не «что лежит», а «что происходило».

А вот понять "что же там происходило", всегда сложнее, чем кажется.

Когда в систему попадает новый пост, это не просто "запись в бд", а момент, когда поток данных смещает нагрузку и меняет контекст.

Чтение поста тоже не про обычный findOne или SELECT. Это ожидание того, что кто-то подготовил данные для чтения, желательно быстрого. Если нет подготовки, значит, система может отдавать данные с задержкой и тормозить поток.

Удаление поста требует, чтобы все связанные данные были стёрты. Пропустил и вот данные уже не консистентны, могут быть ошибки.

Лайк поста это про контроль хаоса, два пользователя пытаются изменить одно и то же. Если не учесть движение потока, гонки могут стать нормой.

Лента вообще живёт, только благодаря предварительной сборке. Кеш, заранее рассчитанный срез, и у системы есть шансы уложиться в SLA.

Всё это не просто функции, это узлы движения данных. Сервис это место, где поток проходит. База это место, где поток оседает. Очередь это место, где поток задерживается.

На этапе проектирования важно видеть всю траекторию движения данных, чтобы не превратить архитектуру в набор случайных, но красивых решений. Даже при выборе правильных инструментов, база, кеш, протокол, если, не учтён поток данных, система начнёт деградировать со старта. Задержки будут расти, хвосты копится, воркеры будут душить CPU, p99 расти.

А что делать-то?

Когда начинаешь смотреть на систему как на средство управления потоком, а не как на набор красивых квадратиков, внезапно становится ясно: Архитектура то, не про сервисы. Она про движение. Сервисы, базы, очереди всего лишь инструменты управления потоком, через которые поток проходит, оседает, задерживается. Важная для понимания механика. Без этого знания будет сложно построить жизнеспособную систему.

Первое, что приходится принять: Поток всегда в движении. Независимо от того, понимаешь ты его или нет. Можешь хотеть идеальный write-API, предсказуемый кеш или волшебный микросервис, который решит все проблемы. Но данные будут идти по своему маршруту, диктуемому задачей, временем, нагрузкой и законами природы. Система будет вести себя так, как движутся данные, а не так, как ты её нарисовал.

Чтобы совладать с потоком, его нужно разложить на три составляющие части: контур записи, контур чтения и контур обработки данных. Каждая часть со своей динамикой, рисками и болевыми точками.

Часть первая: Контур записи

Это write-path. Здесь важно всё: порядок, момент фиксации истины, нагрузка, валидность, скорость реакции. Любая ошибка здесь, как трещина в фундаменте. Ты можешь её сразу не увидеть, но она обязательно проявится позже. Клеппман в DDIA хорошо пишет про то, что write-path это та зона, где принимаются необратимые решения. Если вход нестабилен, никакие кеши и шарды дальше этого не исправят. Вход обязан быть предсказуемым, иначе поток начинает рвать систему в самых неожиданных местах.

Часть вторая: Контур чтения

Вроде как всё просто: достал данные и отдал. Но по опыту, всё далеко не так. В реальности чтение это доминирующий поток. Пользователи читают в десятки раз чаще, чем пишут. И этот поток агрессивный: ему нужна скорость, консистентность в рамках контракта и минимальная логика. Если читать «как есть», напрямую из структуры записи, ничего не получится, дорого, долго, тяжело. Read-path требует данных, подготовленных заранее. Денормализация, кеш, заранее собранные агрегаты, это не оптимизация, это само условие того, что система вообще будет отвечать. Фаулер много писал про этот конфликт: чтение нельзя обслуживать теми же структурами, что запись, если ты претендуешь на SLA, а не на стартап-демку.

Часть третья: Контур обработки данных

Тут вообще обычно проходят мимо, забывают, что, данные в системе преобразуются, обрабатываются, меняются. А потом, ой, кто-то где-то задушил CPU и IO. И начинают поиск обычно с входа, контура записи. А там всё красиво и гладко, не падает, не тротлит. А ведь именно тут происходят самые тяжёлые операции: пересборка агрегатов, обновление статистик, пересчёт связей, материализация, очистка, TTL, миграция, индексация, репликация и много чего ещё. Это тот самый тихий поток, который незаметно работает сутками, пока однажды не попадает в неудачное окно и не начинает давить всю систему. Иногда достаточно одного крупного пересчёта, который внезапно совпал по времени с пользовательским пиком, чтобы p99 ушёл в стратосферу, а в логах появилось много нового и непечатного.

Поток данных порождает сложность, а система, в свою очередь, должна иметь внутренние механизмы, способные эту сложность компенсировать. Ага, да, мы опять пришли к закону Эшби про необходимое разнообразие. База она такая.

Если write-path, read-path и фон неразделены, если у них нет изоляции, буферов, независимых темпов, система становится хрупкой. Это и есть тот момент, когда малейший всплеск нагрузки превращается в неконтролируемую деградацию, а простая операция начинает складывать половину инфраструктуры.

Когда разделение потоков становится очевидным, архитектура начинает выстраиваться сама. Нужна быстрая лента, формируем представление данных заранее. Нужна консистентная запись, уделяем внимание входу, а не тому, как красиво выглядит микросервисная схема. Нужны тяжёлые отчёты, их место в фоне, в собственной вселенной, а не рядом с пользовательскими запросами. Нужны жёсткие SLA, чтение и запись никогда не должны жить в одной структуре данных.

И вот мысль, которую я хотел донести: Многие архитектурные решения не про "инструменты". Они про управление потоком данных. Меняешь форму данных, меняешь поток. Меняешь порядок событий, меняется поток. Убираешь в фон тяжёлые операции, подальше от hot path, меняешь поток. Всё сводится к управлению потоком. Архитектура вырастает из движения, а не наоборот.

Поэтому отвечая на вопрос «_что делать-то?_», ответ простой: Сначала понять свой поток данных, потом разделить его, затем разобраться, как система должна на этот поток реагировать. И только после этого, выбирать инструменты и рисовать стрелочки с квадратиками.

Только в таком порядке. Иначе получится красивая схема и поток говны по ней.

Пример. Своя CDN на монге и немного боли

Представь, что ты делаешь свою «бедную» CDN. Ничего космического, просто раздача статики: картинки, js, css. Пара edge-нод, один origin, всё это крутится рядом с основным приложением. Хочется контролировать версии, уметь быстро откатываться, иногда включать разные варианты для разных клиентов. И вот тут кто-то говорит знакомое: «_давайте всё положим в монгу, сто раз так делали_».

Схема рождается быстро. Файлы лежат где-то на диске или в s3, а в Mongo хранятся метаданные: путь, версия, флаги, список разрешённых клиентов, настройки кеша. Приходит запрос на статику, CDN-нода идёт в Mongo, достаёт документ, понимает, какую версию отдавать, смотрит, не выключен ли ресурс, и уже потом лезет в хранилище. Красиво, гибко, всё динамически настраивается.

На бумаге это выглядит даже красиво. На практике, ну такое.

Контур записи ещё терпимый. Разработчик выкатывает новую версию фронта, сервис релизов пишет пачку документов в Mongo, отмечает новую версию как активную, старую как «archived». Поток данных на входе относительно небольшой, немного всплесков, но монга это переваривает. Все довольны, все ходят и рассказывают, что у них «динамическая CDN с конфигом в базе».

Проблемы вылезают в контуре чтения. Любой запрос на статический ресурс начинает с чтения из Mongo. Даже если у тебя есть локальный кеш файлов на edge-ноде, ты всё равно сначала лезешь в базу: вдруг версию поменяли, вдруг ресурс выключили, вдруг флаг изменился. Пока аудитория маленькая, всё живёт. Как только прилетает бОльшая нагрузка, чтение превращается в поток запросов к Mongo, который, вообще-то, никто не проектировал под роль горячего конфига для CDN.

Монга начинает задыхаться. Планировщик запросов крутит лишние индексы, дисковые операции растут, p95 вылазит за пределы того, что фронт таскает без истерики. Ты добавляешь кэширование на уровне приложения, начинаешь держать конфиг в памяти, придумываешь инвалидацию. Поток чтения уже не выглядит простым: часть идёт в монгу, часть в локальный кеш, часть в соседний узел. И всё это держится на соплях и надежде, что где-то не забыли про invalidate.

А теперь подключается контур обработки.

Бизнес хочет удалять старые версии, чистить неиспользуемую статику, пересобирать манифесты. Пишешь фоновые задачи, которые ночами пробегают по Mongo, ищут старые документы, пересчитывают ссылки, сносят мусор. В какой-то момент этих задач становится много, они начинают работать не только ночью, но и «по расписанию» и «по кнопке». И вот уже поток фоновой обработки лезет в те же коллекции, что и горячее чтение CDN.

Получается красивая каша. Вход пишет новые версии. Чтение при каждом запросе лезет в Mongo, чтобы понять, что отдавать. Фон пересобирает всё это дело, чистит и переиндексирует. Контуры неразделены, темпы у всех разные, буферов почти нет. Достаточно одного неудачного совпадения: деплой, пара «ручных» скриптов по миграции метаданных и пик трафика. Итог предсказуем. Edge-ноды начинают встать на блокировках к монге, CDN «внезапно» перестаёт быть CDN и превращается в дорогой прокси к базе.

Если на это смотреть через призму потоков, картина другая.

На записи тебе вообще не нужна Mongo на hot-path. Нужно один раз зафиксировать факт: «появилась новая версия набора файлов с таким-то идентификатором». Этого достаточно. Подробный конфиг можно материализовать отдельно. В обработке ты спокойно пересобираешь манифесты, генерируешь простой, плоский формат настроек для каждой edge-ноды, кладёшь его в отдельную коллекцию или вообще в файловый снапшот. А контур чтения должен жить своей жизнью: брать уже готовый, прогретый конфиг целиком в память и не ходить в mongo на каждый чих.

В таком варианте поток записи остаётся тонким: немного изменений метаданных. Поток обработки тяжёлый, но изолированный: он пересобирает конфиги, не трогая горячие запросы. Поток чтения максимально простой: один раз в несколько секунд или минут нода подхватывает свежий снапшот конфига, а все пользовательские запросы работают по нему в памяти, не трогая ни Mongo, ни файловое хранилище лишний раз.

Снаружи два решения могут выглядеть похоже: «у нас CDN, конфиг в монге, всё динамическое». Но одно построено как «каждый запрос это маленькое приключение в базу», а второе уже как нормальная работа с потоком: истина пишется отдельно, конфиг готовится отдельно, чтение живёт на готовых срезах.

Формально те же компоненты, та же монга, те же edge-ноды. А по факту в одном случае у тебя постоянная война с пиками, а в другом система, которая хотя бы не стреляет себе в ногу каждый раз, когда кто-то открыл главную страницу.

Что в итоге?

Если смотреть на систему честно, становится видно: она держится не на компонентах, а на движении данных. Пока ты рассматриваешь архитектуру как набор сервисов, все решения остаются косметикой. Поток данных идёт как шёл, и именно он определяет, где появится задержка, где начнёт жрать CPU, где система начнёт деградировать.

Когда разбиваешь поток на контуры: запись, чтение, обработку. Все проблемы приобретают форму. Становится ясно, почему запись должна быть предсказуемой, чтение быстрым, а тяжёлая логика жить отдельно. Пример с CDN на монге это хорошо показывает: одинаковые технологии снаружи дают два совершенно разных поведения в зависимости от того, управляешь ты потоком или таскаешься за ним.

Все архитектурные решения на самом деле про одно: про управление движением данных. Меняешь поток, меняется система. Не меняешь, она меняет тебя.

Поэтому порядок такой же простой, как и беспощадный: увидеть поток, разделить поток, понять реакцию системы – и только потом выбирать инструменты.

В обратном порядке работает только красивая схема и поток говны поверх неё.

Следующая часть как раз будет про реакцию. Про то, что система делает, когда поток выходит из-под контроля. Про обратную связь. Про то, что это, и почему она так важна.

А пока совершенствуйся как специалист и никогда не останавливайся в обучении. Никогда не знаешь, где и когда, какие знания могут пригодиться.

Что еще почитать?

• 2. System design держится на трёх столпах

Допустим, ты успешно собрал требования, был посланы куда-нибудь пару раз, выбил из бизнеса конкретику и понял, что система должна делать и как себя вести. Теперь у тебя есть "документ" с цифрами, SLA, ограничениями, функциональными и нефункциональными требованиями.

Отлично. И вот ты смотришь на этот список, список длинный, много буков и цифров. Что дальше? Как из этого "документа" получить архитектуру?

Для начала нужно налить себе чего-нибудь, например, кофе. Закрыться у себя в кабинете, чтобы тебе никто не мог помешать. А дальше придётся вспомнить много теории и начать думать. Знаю, звучит сложно, особенно про думать, но придётся с этим как-то жить. По-другому никак.

А вспоминать лучше всего начать с трёх столпов любой архитектуры: надёжности, масштабируемости и сопровождаемости. И все три столпа это компромиссы. Каждый из них конфликтует с остальными. Улучшаешь один и ты убиваешь другие.

Не понимая этой базы, любая проектируемая система будет строиться заведомо с меньшими шансами на выживание в реальном мире. С каждым шагом ты будешь желать всё сжечь и уволиться всё больше и больше.

Поэтому предлагаю тебе устроиться поудобнее и почитать про базу system design.

Что там за столпы такие?

Начну сразу с ремарки: надёжность, масштабируемость и сопровождаемость это не красивые слова из ролика на ютубе или презентации. Это конкретные инженерные свойства системы, их можно измерить, потрогать, пощупать.

Надёжность — это способность системы работать в условиях, когда вот-вот всё упадёт и когда уже часть упала. Не "не падать никогда", а "падать предсказуемо и восстанавливаться быстро". Предсказуемая деградация функциональности. Какой таргет по доступности? Что происходит при отказе компонента? Как быстро система возвращается к нормальной работе? Можно ли и какие данные терять при сбое?

Масштабируемость — это способность системы справляться с ростом нагрузки без деградации качества. Не "держать любую нагрузку", а "держать запланированную нагрузку в рамках SLA". Как система ведёт себя при 2x, 10x, 100x росте трафика? Где появляются узкие места? Можно ли масштабировать по частям или только целиком?

Сопровождаемость — это способность системы изменяться без катастрофических последствий. Не "код должен быть красивым", а "изменения должны быть предсказуемыми и безопасными". Сколько времени уходит на добавление фичи? Как часто изменения ломают что-то ещё? Можно ли откатить изменения? Сколько людей нужно для поддержки системы?

Вот эти три свойства и определяют архитектуру. Все три свойства противоречат друг другу. Постоянная борьба за баланс и компромисс.

Почему же они конфликтуют?

Потому что мир конечен. У тебя ограниченный бюджет, ограниченное время, ограниченные ресурсы. И каждое решение, которое улучшает одно свойство, ухудшает другое.

Хочешь надёжность? Добавляешь реплики, валидацию, проверки, мониторинг. Пишешь код для контролируемой деградации, отлаживаешь управляемую остановку сервисов. Добавляешь код для работы с граничными случаями. Система становится сложнее, медленнее, дороже. Появляется больше абстракций. Сопровождаемость падает. Больше кода, больше конфигов, больше точек отказа.

Хочешь масштабируемость? Разносишь по серверам сервисы, добавляй кеши, настраиваешь шардинг, появляется желание завозить очереди, прости господи. Пишешь больше кода для обеспечения согласованности. Думаешь в сторону микросервисов и распределенки. Система становится сложнее, появляются новые типы сбоев, консистентность данных страдает. Надёжность падает. Больше компонентов, больше сетевых вызовов, больше вероятность упасть.

Хочешь сопровождаемость? Упрощаешь архитектуру, минимизируешь зависимости, пишешь простой код. Но система становится менее гибкой, хуже масштабируется, сложнее оптимизируется. Думаешь в сторону монолита. Масштабируемость падает. Масштабирование по частям становится практически невозможным, нельзя использовать некоторые инструменты.

К сожалению, таковы законы природы. Нельзя получить всё, везде и сразу. Постоянный торг, постоянный поиск компромиссов.

Пример

Давай покажу примеры, как эти компромиссы работают на практике.

Кеш vs консистентность

Начнём с классики. Хочешь скорость? Добавляй кеш. Данные читаются из памяти, ответы прилетают быстрее. Масштабируемость растёт, нагрузка на базу падает.

Но что происходит с консистентностью? Данные в кеше могут быть устаревшими. Пользователь видит старую информацию. Если кеш упал, время ответа кратно возрастает. Если кеш переполнился, часть данных вытесняется.

Можешь добавить инвалидацию кеша, но тогда кеш становится сложнее. Можешь использовать write-through, но тогда записи становятся медленнее. Можешь использовать eventual consistency, но тогда пользователи видят разные данные в момент времени.

Выбор зависит от требований. Для ленты новостей eventual consistency это нормально. Для банковского баланса совершенно неприемлемо.

Микросервисы vs простота

Хочешь независимые релизы и масштабирование по частям? Завози микросервисы. Каждый сервис можно разрабатывать, тестировать и деплоить отдельно. Команды не мешают друг другу.

Но что происходит со сложностью? Появляются сетевые вызовы, нужно думать про таймауты и ретраи. Руки тянутся к очередям, сложность x10. Данные размазываются по сервисам, консистентность становится проблемой. Отладка усложняется, практически неминуемая большая связность, один запрос проходит через десяток сервисов.

Можешь добавить service mesh, но тогда появляется ещё один слой абстракции. Можешь использовать event sourcing, но тогда система становится ещё сложнее. Можешь минимизировать количество сервисов, но тогда теряешь преимущества микросервисов.

Примерно тут ты вспоминаешь про саги. Способ склеить распределённые транзакции без 2PC. Каждая операция локальна, но цепочка координируется сообщениями. Если шаг падает, запускается компенсирующее действие. В теории красиво, на практике превращается в ад отложенных событий и "ручного" восстановления состояния. Любая ошибка в оркестрации, и данные начинают расходиться.

Выбор зависит от размера команды и сложности предметной области. Для стартапа из трёх человек микросервисы это оверинжиниринг. Для команды из ста человек монолит будет якорем.

Синхронность vs асинхронность

Хочешь простоту и предсказуемость? Делай всё синхронно. Запрос пришёл, обработался, ответ ушёл. Легко отлаживать, легко тестировать, легко понимать.

А что с производительностью? Медленная операция блокирует весь запрос. Если один компонент тормозит, тормозит вся система. Масштабировать можно только вертикально.

Можешь добавить очереди, прости господи, но тогда появляется eventual consistency. Можешь использовать неблокирующие вызовы, но тогда код становится сложнее. Можешь разбить операцию на этапы, но тогда нужно думать про компенсацию, привет саги.

Выбор зависит от требований к задержкам и пропускной способности. Для систем реального времени синхронность может быть критична. Для batch-обработки асинхронность это необходимость.

И как выбирать эти ваши компромиссы?

Ага, примерно тут, ты достаёшь из широких штанин, толщиною с консервную банку, хм, документ. Тот, что ты собирал с боем в прошлый раз. Требования. Каждое архитектурное решение должно быть обосновано конкретной строкой или абзацем в этом документе.

Если бизнес кричал «нужна скорость», теперь ты смотришь какой ценой. Где они согласились терпеть боль. Медленную запись? Потерю консистентности? Сложность кода?

Если требовали «надёжность», ты открываешь SLA и смотришь, что на самом деле под этим имелось в виду. Сколько минут даунтайма они готовы пережить, сколько данных потерять, какие ошибки простить.

Если просили «простоту» ищешь, для кого именно. Для разработчиков, чтобы быстрее пилить фичи? Для пользователей, чтобы не путались в интерфейсе? Или для эксплуатации, чтобы не вылавливать зомби-процессы ночью?

Тут появляется концепция "бюджета боли". У тебя есть ограниченный бюджет на сложность, на производительность, на надёжность. Ты не можешь получить всё сразу. Ты можешь только осознанно распределить этот бюджет.

Что за бюджет такой?

Представь, что у тебя есть сто деняк. Ты можешь потратить их на надёжность, на масштабируемость или на сопровождаемость. Но на всё сразу у тебя не хватает.

Если потратишь всё на надёжность, получишь систему, которая не падает, но тормозит и которую никто не понимает. Если потратишь всё на масштабируемость, получишь систему, которая держит нагрузку, но падает от любого чиха. Если потратишь всё на сопровождаемость, получишь систему, которую легко поддерживать, но которая не масштабируется.

Правильный подход потратить бюджет осознанно. Понять, что важнее для твоего конкретного случая, и вложиться в это. А в остальном принять компромиссы.

Пример: система уведомлений

Допустим, тебе нужно построить систему уведомлений. Бизнес говорит: "Нужно отправлять уведомления пользователям. Быстро, надёжно, много."

Ты собираешь требования и понимаешь:

• 100k пользователей, 10k уведомлений в день
• Время доставки не критично, можно в течение минуты
• Потеря 1% уведомлений допустима
• Команда из пяти человек, бюджет ограничен

Теперь ты можешь осознанно выбирать компромиссы:

Надёжность vs простота: Можно сделать простую систему, один процесс, одна база, прямой вызов. Но если процесс упадёт, часть задач потеряется. Можно добавить репликацию и мониторинг, но система станет сложнее.

Масштабируемость vs консистентность: Можно гарантировать, что каждое событие будет обработано ровно один раз, но тогда придётся решать вопросы дубликатов и идемпотентности. Можно выбрать eventual consistency, но тогда часть данных может устаревать или теряться.

Сопровождаемость vs производительность: Можно написать простой и прозрачный код, который легко читать и менять. Но он не выдержит пиков. Можно добавить кэширование, пайплайны и оптимизации, но код станет запутаннее и более хрупким.

Исходя из требований, ты выбираешь: простота важнее надёжности (1% потерь допустимы), eventual consistency важнее строгой консистентности (задержка не критична), простота важнее производительности (нагрузка невысокая).

Получается простая система: прямые вызовы, базовая обработка ошибок, минимальный контроль состояния. Не идеально, но соответствует заявленным требованиям.

Что в итоге

System design это не про то, чтобы найти "правильную" архитектуру, тем более не про "чистую". Правильной архитектуры не существует. Есть только архитектура, которая подходит под твои требования и ограничения, и даёт шанс на выживание проекта.

Три столпа: надёжность, масштабируемость и сопровождаемость. Три, казалось бы, простых таргета, которые есть в каждой системе, причиняют огромное количество боли. Особенно, если наступить не в тот компромисс или войти не в ту дверь.

Искусство настоящего архитектора - умело жонглировать этой болью, принимать решения, жертвовать, ради достижения поставленной цели.

Рождение архитектуры, в котором помогает system design, интересный, тяжёлый и завораживающий итеративный процесс, поучаствовать в котором я всем желаю.

В следующий раз попробую показать на примере, как последовательно от требований, от документа, толщиною с консервную банку, перейти к архитектурному решению с шансами на жизнь.

А пока читайте книги, всем добра.

Что еще почитать?

• 1. System design начинается с вопросов
• [High Scalability — Real World Architectures](http://highscalability.com/) - много интересных примеров
• Martin Fowler — Microservices Trade-Offs - про компромисы в микросервисах

Обычное утро понедельника. Ничего не предвещало беды. Ты наливаешь кофе, открываешь бук, пуллишь проект и начинаешь читать ночные коммиты от коллег. Тишина, спокойствие, идиллия.

И вот он. Мерзкий, пронзающий сознание звук уведомления, от которого сводит зубы. Тебе пишет PM. Сворачиваешь проект с опаской и дурным предчувствием, открываешь диалог. А там две строчки.

“_Бизнес хочет ленту как у Threads. Какие сроки?_”

И вот тогда это происходит. Момент, когда дыхание замедляется. Ты переживаешь весь спектр эмоций. Сонм мыслей: "_Какая вам… лента? Мы же сайт для учёта бобров_", "_А Твиттер вам не написать?_". Мимо пролетают стадии от гнева до принятия.

Вдох, выдох. В такие моменты кажется, что согласиться и разбираться по ходу дела приемлемая стратегия. Но если принять такие правила игры, ошибки могут быть очень дорогими.

За красивой формулировкой про "ленту" нет конкретики. Ничего измеримого. Буквально ты не знаешь ничего.

Если сейчас не докопаться до сути, не собрать конкретные ожидания и измеримые показатели, дальше будет только хуже. Вместо простого проекта получится "челмедведосвин". Ты не сможешь его поддерживать. Вносить изменения будет сложно, развитие станет пыткой.

А что ты можешь сделать? Для начала пишешь PM: “_Мне нужно собрать требования. Организуй встречу_”.

И начинаешь подготовку к сражению. Твоим оружием будут сотни неудобных, повторяющихся и дотошных вопросов. Твоей победой станет метаморфоза влажной фантазии бизнеса в конкретные требования к проекту.

Вот почему system design начинается с вопросов, а не со схем. Вопросы это первая ступень к архитектуре. Архитектуре, которая будет работать в реальном мире, а не на бумаге.

Какие вопросы задавать и зачем, я сейчас расскажу.

Почему вопросы это не просто формальность

Вся эта история с вопросами кажется банальной. Ну спросил, ну ответили, ну записал. Что тут сложного? А сложного тут всё.

Бизнес говорит на языке результатов. "_Хотим ленту_", "_нужна аналитика_", "_сделайте как у конкурентов_", "_сделай чтоб работало_". Это нормально, они не обязаны знать, что такое eventual consistency или почему Redis не подходит для персистентного хранения.

Твоя задача перевести эти хотелки в технические требования. И вот тут начинается самое интересное.

Каждое "хочу" скрывает десятки неявных предположений. Бизнес не думает о том, что лента должна работать при 10k RPS, что данные могут быть неконсистентными первые 5 секунд, что при падении сервиса пользователи должны видеть кеш, а не белую страницу.

Они просто хотят, чтобы "_всё работало_". А что значит "_работало_" это уже твоя головная боль.

Вопросы не придирки и не попытка усложнить простую задачу. Это способ вытащить на свет все те скрытые требования, о которых бизнес даже не подозревает.

Без этого ты будешь строить систему вслепую. Сделаешь что-то, что технически работает, но не решает реальную проблему. Или решает, но с такими компромиссами, что через полгода придётся всё сжечь и написать заново.

Какие вопросы задавать

Вопросы должны вытаскивать не просто пожелания, а фундаментальные ограничения системы. Архитектура это компромиссы между противоречивыми требованиями. Твоя задача найти эти противоречия до того, как они сломают систему в проде.

Начни с формальных требований, которые можно измерить и потрогать. Сколько пользователей, какие запросы, как долго система может отвечать. Это основа для всех дальнейших решений. Без цифр и строгих таргетов у тебя не проект, а путь самопознания. Если не повезёт, путь закончится не продом, а дуркой.

Но формальные требования это только верхушка айсберга. Под ними лежат неформальные требования, те, что бизнес даже не осознаёт. Что происходит, когда система падает? Пользователи ждут или уходят? Можно ли показать устаревшие данные? Что важнее, скорость или точность?

Эти неформальные требования часто противоречат друг другу. Хочешь скорость, жертвуешь консистентностью. Хочешь надёжность, усложняешь систему. Хочешь простоту, ограничиваешь функциональность. Это неизбежные компромиссы. Их нельзя избежать, можно только осознанно выбирать.

Не существует серебряной пули. Каждое простое решение скрывает за собой сложность. Когда бизнес просит "ленту как у Threads", он просит именно такую пулю, магическое решение, которое решит все проблемы без компромиссов. Твоя задача показать, что такой пули не существует, и помочь выбрать правильные компромиссы.

Здесь вступает в игру кибернетика. Есть закон необходимого разнообразия. Система может справиться с разнообразием внешней среды, только если у неё есть достаточное внутреннее разнообразие реакций. Проще говоря, если мир вокруг сложный, твоя система тоже должна быть сложной.

Но сложность это не хаос. Это структурированная сложность, где каждый элемент имеет роль и ограничения. Твои вопросы должны выявить не только что система должна делать, но и как она должна реагировать на изменения, сбои, пики нагрузки.

Каждое техническое противоречие можно решить, если правильно его сформулировать. Не "_нужна и скорость, и надёжность_", а "_скорость там, где важно не тормозить, надёжность там, где нельзя упасть_". Не "_нужна и простота, и функциональность_", а "_простота для тех, кто просто пользуется, функциональность для тех, кому это нужно_".

Твои вопросы должны вытаскивать эти противоречия на поверхность. Что важнее: время разработки или время отклика? Стоимость инфраструктуры или доступность? Простота поддержки или богатство функций?

Каждый ответ на твой вопрос должен приводить к архитектурному решению. Если бизнес говорит "_нужна скорость_", ты спрашиваешь "_Чем можно пожертвовать ради скорости?_". Если говорят "_нужна надёжность_", ты спрашиваешь "_Что считается сбоем?_". Если говорят "_нужна простота_", ты спрашиваешь "_Простота для кого? Для разработчиков? Для пользователей? Для бизнеса?_".

Без этих вопросов ты будешь строить систему, которая решает не ту проблему. Или решает правильную проблему, но с неправильными компромиссами. Или с правильными компромиссами, но в неправильном контексте.

Как задавать вопросы

Сбор требований это не одноразовая встреча. Это итеративный процесс, где каждый цикл углубляет понимание и выявляет новые противоречия. Это архитектурное мышление, способность видеть систему как набор взаимосвязанных компромиссов.

Есть два типа сложности: сущностная и случайная. Сущностная это то, что нельзя убрать, не изменив саму задачу. Случайная это то, что мы добавляем сами, неправильно понимая требования. Твои вопросы должны выявить сущностную и минимизировать случайную.

Начни с широкого контекста. Собери всех заинтересованных лиц и задавай открытые вопросы. Как сейчас работает процесс? Что больше всего бесит в текущем решении? Что будет, если ничего не менять? Цель понять общую картину, не вдаваясь в детали.

Записывай всё. Даже то, что кажется неважным. Потом разберёшься. Часто самые важные ограничения скрываются в мелочах, которые кажутся очевидными.

Теперь иди к каждому стейкхолдеру отдельно. У них разные интересы и приоритеты. Продукт думает про пользовательский опыт, бизнес про деньги, эксплуатация про стабильность. Каждый видит систему под своим углом, и твоя задача собрать эти углы в единую картину.

Не принимай ответы типа "_ну, как обычно_" или "_сделайте нормально_". Докапывайся до цифр. Если говорят "_быстро_", спрашивай "_Что для вас значит быстро? Сколько миллисекунд, секунд?_". Если говорят "_надёжно_", спрашивай "_Что считать сбоем? Сколько девяток доступности? Что видит пользователь при сбое?_".

К этому моменту у тебя будет список требований длиной в километр. Большинство из них будут противоречить друг другу. Это нормально. Система живёт в мире ограниченных ресурсов, где нельзя получить всё сразу.

Время для взрослых разговоров. Что важнее: скорость или надёжность? Простота или функциональность? Бюджет или качество? Не пытайся угодить всем. Лучше честно сказать "_это требование увеличит сроки в два раза_" и дать бизнесу принять решение.

Оформи всё в документ. Не в виде списка пожеланий, а в виде конкретных, измеримых требований. "_Система должна поддерживать тысячу одновременных пользователей_" вместо "_должна быть надёжной_". "_Время ответа API не должно превышать 200 миллисекунд в 95 процентах случаев_" вместо "_должна работать быстро_".

Этот документ станет основой для всех дальнейших решений. Каждое архитектурное решение должно быть обосновано конкретным требованием из этого документа. Если не можешь объяснить, зачем нужен тот или иной компонент, значит, этот компонент лишний.

Посмотрим как это работает на примере.

Cценарий 1: Сам решил

PM приходит с задачей. "_Бизнес хочет ленту новостей. Сделайте как у Threads_".

Ты спрашиваешь: "_А что именно имеется в виду?_"

PM отвечает: _"Ну, лента. Где посты идут в хронологическом порядке, с лайками и комментариями"_.

Вроде понятно. Ты киваешь, но в голове уже крутится: "_А что, если пользователей будет много? А если нагрузка вырастет? А если понадобится поиск?_".

Хоронишь эти вопросы в себе и накидываешь схему. Таблицы posts, likes, comments. API для получения ленты. И вроде красиво. Микросервисы. Кафка, прости господи, чтобы общались. Valkey за кэш. Поиск на эластике. Ну и докер, кубер, графана, прометеус. Всё как у взрослых.

Через месяц выкатываешь на прод. Сотня пользователей заходит одновременно, и система падает.

Бизнес задаёт неудобные вопросы: "Почему ничего не работает? Почему так медленно? У Threads же быстро работает!"

Ты начинаешь оптимизировать. Добавляешь кеши, тюнишь Kafka, добавляешь реплики. Каждая правка ломает что-то ещё. Через полгода у тебя зоопарк микросервисов, devops-шапито и система, которую никто не понимает, и все боятся трогать. Поздравляю, ты создал legacy.

Cценарий 2: Наорал

Ты не киваешь. Ты хватаешь PM, привязываешь его к стулу и начинается, хм, диалог.

Ты задаёшь вопросы. Сначала PM. Кто пользователи? Сколько постов в день? Кто пишет? Что пишут? Как часто заходят? А сколько пользователей через пол года, год? Что важнее, скорость или актуальность? Что считается сбоем? Можно ли показывать устаревшие данные?  А нужна аналитика? А архивировать будем? Поиск нужен? Реагируем на лайки сразу? Комментарии сразу видно? А подписки? А уведомления? И так далее.

Потом идешь вместе с PM пытать бизнес и эксплуатацию.

Через несколько дней у тебя полная картина. 5к активных пользователей. Сто постов в день. Пик нагрузки в обед и вечером. Главное — скорость. Можно жертвовать актуальностью лайков и комментариев. Простои до получаса допустимы. Архивируем через пол года. Поиск простой. Рост медленный. И тд. и тп.

Ты делаешь схему под это. Одна таблица posts с денормализованными данными. Один Valkey для кеша с TTL пять минут. Никакой плеяды микросервисов. Никаких очередей. Одна база, один сервис.

Лента открывается быстро. Система держит нагрузку. Код простой, понятный, надёжный. Бизнес доволен. Тебе не задают неудобные вопросы.

Всё то модное, что ты впихнул в первом сценарии, оказалось ненужным.

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

Что в итоге

System design это не про схемы. Это умение задавать правильные вопросы и вытаскивать из бизнеса реальные требования, а не слепо следовать его влажным фантазиям.

Без вопросов ты строишь систему вслепую. С вопросами решаешь конкретную задачу конкретными средствами.

Но вопросы это только начало. Дальше нужно понять, как переводить требования в архитектурные решения, выбирать правильные компромиссы и не поддаваться на соблазн "_сделать как у больших дядек_".

В следующих частях расскажу, почему system design держится на трех принципах, как из требований получается архитектура, как выбирать правильные компромиссы и почему простое решение часто лучше сложного.

А пока перестань кивать на хотелки бизнеса и начни задавать неудобные вопросы. Скажешь себе потом спасибо.

Что еще почитать?

• 0. System design – это тебе не квадратики рисовать
• Ordering Interrogative Questions for Effective Requirements Engineering: The W6H Pattern - немного академки
• System Design: Чек-лист по сбору и фиксации требований на все случае жизни - больше конкретики
• Бунин О.В. Highload 1. Сбор требований. Фронтенд-бэкенд - оч советую посмотреть этот курс целиком

В начале карьеры все архитектурные вопросы сводятся к проектированию малых частей системы. Все в пределах одного сервиса. Немного думаешь про базу, немного про, прости господи, очереди, чуть-чуть про оптимизацию.

Обо всем остальном думают умные дядьки. Они рассказывают, зачем ты пишешь этот сервис и какие требования к нему. Скажут, какую бд взять, какой язык использовать и как сделать так, чтобы держало нагрузку. Остальное дело техники: пара паттернов, охапка костылей – сервис готов. Можно перекладывать json’ы.

Проходит несколько лет, и твой умный дядька исчезает. PM приходит уже к тебе. И вдруг выясняется: теперь именно ты отвечаешь на неудобные вопросы и должен объяснить, как строить сервис.

Последний год ты много слышал про system design, но не обращал внимания. Думал, это для больших и умных. Слышал, что он про архитектуру. Его хотят на собесах. Там рисуют квадратики и стрелочки: квадратики становятся сервисами, базами, кешами и (прости господи) очередями , стрелочки - каналами связи.

Посмотрел ютуб, посмотрел прошлые сервисы, подумал и нарисовал. Рассказал команде. Они постарались и сделали. Сервис выкатили на прод.

Сервис крутится, бизнес мутится, растет нагрузка. Растут задержки. Сервис начинает задыхаться и падать, downtime растет. Всё чаще тебе приходится отвечать на вопросы, на которые раньше отвечали другие.

Ты идешь советоваться к умными дядьками из других команд и компаний. Они почему-то в разрез с ютубом мало говорят про квадратики и стрелочки. Они говорят про какого-то Клепмана, про Эшби и кибернетику, про Альтшуллера и ТРИЗ.

Тебе говорят, что system design это про компромиссы: надежность, масштабируемость и сопровождаемость. Говорят, что мало один раз нарисовать — нужно возвращаться, пересматривать, менять архитектуру под новые боли и требования. Что нужно собирать эти требования. Что схем должно быть много: для бизнеса — своя, для девопсов — своя, для разработки — своя. Разные уровни абстракции, разные нюансы.

И все это – теперь хотят от тебя. Мрак. Ужас.

Поэтому, пока не поздно, я предлагаю тебе погрузиться со мной в знакомство с system design. Я не буду рассказывать «как пройти собес». Я расскажу тебе: почему system design не про стрелочки и квадратики, зачем тебе он нужен и как он может облегчить твои страдания.

Что же такое «System design»?

Чем System design точно не является: рисованием и инструментом для прохождения интервью. Так его блоггеры на ютубе продают. Так проще. Но реальность гораздо сложнее.

System design - это спор с реальностью, борьба с ограничениями, поиск компромиссов. Это мир, в котором у каждой идеи есть цена, у каждого ограничения есть причина. Это мир, в котором "правильная архитектура" сейчас становится "неправильной" через пару месяцев.

Любая система живет в изменчивой среде, и твоя задача – сделать так, чтобы она не была хрупкой, выгибалась и деформировалась, но не ломалась с треском. Это свойство системы: гибкость. Это способность пережить пик нагрузки, переварить новый источник данных, выдержать новый SLA, предоставить новый контракт. При этом не сломать команду, которая разрабатывает систему.

С осознанием этого, ты скорее всего придешь к первой взрослой мысли: «нужно собрать требования». Это на первый взгляд просто. Спросил, чего хотят, сделал что-то похожее. Но нет.

Собирать нужно с умом. Формулировка: «хотим ленту как у Threads” не подойдет. Нужно выбить из бизнеса и аналитиков конкретику: сколько пользователей планируется на старте, сколько через год, сколько времени у тебя на p99, какой сбой считается нормой, чем можно пожертвовать при пиках, важнее истина или скорость, чем бизнес готов жертвовать взамен на экономию.

Если всего этого не узнать в начале, ты рисуешь картинку — сферический сервис в вакууме, который красиво выглядит на схеме, но не имеет ничего общего с реальностью. Подробнее поговорим отдельно. Сбор требований важная большая тема.

После сбора требований логически появится следующая мысль: "нужно определить технологический стек". Это не про знать все языки и инструменты, это не про держать в голове энциклопедию, это не про культ «возьмем модный брокер». Это простой расчет.

Требования дают представление: «такой профиль данных, здесь читаем, тут пишем, такие хвосты распределения, такие пики». Отсюда вытекают формат данных, модель консистентности, понимание, что журнала хватит и очередь не нужна, что вот тут может быть узко, а тут проблем быть не должно. Ты уже прикидываешь, нужен ли hot path в памяти, и чем придётся платить за восстановление.

Стек складывается естественно: какие составные части, на чём они будут написаны, какие инструменты лягут в основу. Эти мысли уже можно переносить в ТЗ и схемы.

Что-то уже есть на бумаге и технологический стек первично определен. Начинаешь погружаться глубже. Теперь нужно работать со связями. Мысль три: «нужно определить поток данных и обратную связь системы».

На этом этапе зачастую красивые презентации заканчивается. Поток данных это не просто стрелочки от сервиса к сервису. Нужно описать ритм, как система будет жить. Где данные зарождаются, как они движутся по системе, где данные накапливаются, где могут упереться в ботлнек, где задерживаются.

И главное - как система реагирует, когда на нее давят. Не существует «пассивной» системы: если разнообразие воздействий мира на систему больше спектра ее реакций, система уходит в отказ.

Если по-простому: поток данных должен быть сопряжён с обратной связью. Когда вход растёт быстрее, чем ты можешь переварить, ты либо сигнализируешь «стоп, хватит» (backpressure), либо начинаешь управляемо деградировать. Не «всё для всех, но “сдохли”», а «меньше, но вовремя».

И вот здесь начинает появляться настоящая архитектура: система, которая умеет не геройствовать до смерти, а вовремя сказать «нет» и остаться живой.

Если обобщить: System design всегда живёт на четырёх слоях: технологическом, организационном, фундаментальном и изобретательском. Игнорируешь хоть один и система падает не там, где ждёшь, а там, где больнее всего.

Посмотрим на примере

У тебя небольшой сервис в HFT-экосистеме. Клиенты сами парсят разные внешние источники и приводят данные к формату, нужному системе.

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

Но реальность бьет по твоей картинке цифрами. Бюджет задержки жесткий. Данные устаревают буквально спустя пару сотен миллисекунд, а еще нужно принять решение и это решение обработать. Бизнесу важнее своевременность, чем богатая обвязка вокруг каждого события. И да, падать система может, но подниматься обязана быстро, без долгих реплеев и нескольких минут на холодный старт.

С этого места любая «идеальная» схема превращается в торги с реальностью. Сначала ты, под влиянием общественности, кладёшь между нормализацией и обработкой брокер сообщений. Красиво: есть буфер, есть независимость потребителей, есть история. Но под всплесками у тебя начинается разброд в хвостах: холодные консьюмеры приходят не вовремя, очереди пухнут, рваные задержки делают p99 некрасивым. Да, это отчасти лечится, но чудес не бывает, ты платишь за удобство бэклога лишними миллисекундами и нестабильностью хвостов.

Ок, пробуешь подойти с другой стороны. Выносишь горячий путь целиком в память. Кольцевой буфер, предсказуемость, минимум аллокаций, никакой тяжелой сериализации. Красота, пока всё живо. Как только система падает, выясняется, что воспроизводимость историй тебе нужна не назавтра, а сейчас. Иначе ты либо принимаешь решения «вслепую», либо тормозишь прод ради восстановления. Местами это допустимо, но обычно — нет.

В какой-то момент ты перестаёшь играть в чёрно-белое и делаешь так, как делают взрослые: разделяешь истину и скорость.

Горячий путь идёт по памяти и держит SLA, а рядом ты пишешь минимальный, но надёжный журнал, из которого можно подняться, догнать и перепроверить. Не «всё и сразу», а ровно столько, чтобы после падения не начинать жизнь заново. Это дороже по ресурсам и по мозгам: двойная запись, идемпотентность, продуманная консистентность. Зато вместо религиозного спора «брокер или память» у тебя работает система, объединившая оба подхода.

Дальше больше, завозишь дисциплину. Ты привязываешь поведение к метрикам: когда хвосты начинают расти и превышают допустимые значения, обедняешь обработку, сохраняешь ядро.

Ты не глотаешь бесконечный вход, ты просишь столько, сколько способен обработать, а остальное честно отклоняешь. Выбираешь обратимость действий, чтобы не держаться за «идеальную транзакцию» в распределённой грязи.

Оформляешь эти решения словами, которые команда понимает: здесь у нас компенсирующая логика, тут мы разносим запись и чтение в разные модели, тут у нас предохранитель, тут выбрасываем «дорогое» обогащение при перегреве.

А далее, ты регулярно возвращаешься к схеме, не чтобы «дорисовать рамку», а чтобы проверить, что текущее поведение соответствует изменившимся требованиям.

С этого места становится видно главное. System design не про то, чтобы однажды красиво объяснить «как мы всё построим». Это про способность системы и команды менять форму, не теряя сути. Про честные компромиссы между скоростью и истиной, между простотой и гибкостью, между идеалом и тем, что реально держит прод. И да, про изобретательность по ТРИЗ: не «выбрать единственно верный инструмент», а развернуть противоречие так, чтобы выиграть временем и уменьшить боль.

Вывод

System design это широко, сложно и очень интересно. Это не про квадратики и стрелочки. Это про то, как разговаривать с реальностью на языке требований, обратной связи и компромиссов. Если твоя схема выдерживает новый источник, новый SLA и новый сбой без капитального ремонта, значит, ты всё сделал правильно. Всё остальное — декор.

Что еще почитать?

• Sean goedecke. Everything I know about good system design
• Intercom. Six principles of system design

Каждый  разработчик думает об архитектуре нового проекта,  и часто приходит к такому заключению: «_Завезу микросервисы, и чтоб красиво кафку туда, или реббит, чтоб общались. Редис для кешей, и все это в кубере. Заживу!_».

Обоснование тому такое: «_Задел на будущее, кучу систем так построили, нормально работает, даже не больно, практически. И распределенка, и отказы с пиками держим. Красота!_». Я мог бы согласится, но не буду. Если начать копать глубже, всплывает много нюансов. Большую часть того, что всплывает, я описал в прошлый раз.

Тогда же, в комментариях, чтобы не быть голословным и ради академического интереса, решил собрать стенд и уже на цифрах тебе показать, что очереди в классическом понимании все еще не нужны.

Расскажу что собирал, как и что измерял и какие результаты получил.

Часть первая: Преамбула

Начну издалека, с теоретического обоснования, как учили еще в университетах.

Есть у тебя сервис А. Базу свою этот сервис и в хвост и в гриву, поэтому запись там медленная — допустим, 60 мс. Сервис А принимает на эндпоинт /task задачу, а бизнес вместе с SRE говорит тебе как архитектору: «_Ждать ажно 60мс никак не можем, ответить нужно за 50 и точка. Zero loss, идемпотентность, at-least-once. Ещё давай, чтобы graceful degradation было, throughput не падал, latency стабильно в SLA. Ordering guarantees можно не жёсткие, но durability кровь из носа. И чтоб backpressure обязательно. Завтра релиз_».

Отдельное спасибо бизнесу, что порядок записи не так уж и важен, и этим ты можем пренебречь, то есть писать можно параллельно пачками и быстрее разбирать хвост.

Формализуем требования:

• SLA входа: p99(t_api) ≤ 50 мс при 500 RPS (без аварий).
• At-least-once доставка без дублей в целевой БД (идемпотентность по id).
• Durability на приёме: после ответа клиенту запись потеряться не должна при падении сервиса/воркера/базы.

Остальное как бы не услышал, оно тебе не важно.

Уяснив требования бизнеса и хотелки SRE, наливаешь кофу и начинаешь думать, какие варианты у тебя есть и чего эти варианты тебе будут стоить.

Часть вторая: Кейсы

Возьмем сферический проект в вакууме, представим, что у тебя нет ничего кроме как api и базы. Api напрямую пишет задачу в бд и беспощадно нарушает SLA.

"_Чтож делать? Чтож делать?_"

Кейс 1. WAL (Write-Ahead Logging)

Старый “советский” метод. Api пишет не в базу, а в локальный журнал. Формат тупой как гвоздь: длина + payload. Один fsync на батч или по таймауту. Ротация — по размеру и времени. Старый сегмент закрыли, новый открыли. Воркеры читают завершённые сегменты и докатывают в базу пачками, хоть по 100, хоть по 1000 штук.

Плюсы: – Latency +-1 мс на входе (fsync по батчу/таймеру). – Durability честная после fsync. – At‑least‑once через идемпотентность в БД. – Failover тривиальный (перечитываем сегмент). – Естественный backpressure по росту сегментов.

Минусы: – Дисковая нагрузка (особенно fsync=always). – Своя реализация и поддержка (скорее всего реализации готовой не будет или будет написана индусом). – Нужен мониторинг лага/ротации, контроль места на диске.

WAL – это "скучный" вариант, но и предсказуемый, сам сломал –сам чинишь. Нет брокеров, нет «кластеров», нет магии. Файл и логика: как писать, как читать, как ротировать. Стоит упомянуть, что все последующие кейсы в той или иной степени под капотом имеют схожий механизм обеспечения сохранности данных – fsync.

Кейс 2. Ingest DB

Тут уже будет нужен DevOps. Вместо того, чтобы писать в журнал, пишем сразу в базу — но не в боевую, а в отдельный инстанс (ingest), который не тормозит, заточен на быструю запись и физически крутится на другом сервере.  Уже из него воркер параллельно пачками переливает в нужную базу.

Плюсы: – Durability на стороне СУБД. – Дубликаты гасит ON CONFLICT. – Масштабирование воркерами, размер пачки. – Лаг прозрачен (ingest → main).

Минусы: – Индексы на ingest могут тормозить вставку. – Вакуум/блоат и размер пачки нужно тюнить. – UNLOGGED нельзя при zero‑loss. – Возможна гонка за ресурс на горячих партициях. – Медленная/общая БД = боттлнек.

Получается, что IngestDB — это в теории решение между чистым WAL и брокером. Простая вставка на входе, батчи на выходе, минимум инфраструктуры. Теоретически хорошее решение, завез отдельную базу, затюнил и решил проблему.

Кейс 3: Valkey (Streams с AOF)

Вот ты уже практически прям рядом с очередью. Еще не жирный брокер, но уже очередь на минималках. Берём Valkey (форк Redis), включаем streams и appendfsync=always. Тут как и с базой нужОн DevOps, лучше два, поднимаем новый отдельный сервис.

А работает кейс так: – api пишет событие в XADD stream * payload. Операция быстрая, но не бесплатная, каждый fsync блокирует запись. – Клиент получает ACK сразу после попадания в AOF, значит durability честная. – Воркер читает через XREADGROUP, обрабатывает пачку и помечает offset.

Плюсы: – Низкая теоретическая базовая задержка на XADD. – AOF даёт честную durability. – At‑least‑once встроен (PEL/ACK) (с оговоркой, только на доставку, дубли не контролируются). – Привычный стек (в теории).

Минусы: – p99 скачет из‑за fsync на нагрузке. – Backpressure кривой: растёт лаг, сервис ест память. – Failover: потеря хвоста без WAIT/min‑replicas‑to‑write. – Доп. сервис и зоопарк, рост RAM до краша.

Valkey хорош для UX-шных событий, коротких очередей, быстрых стримов, где пропускная способность важнее стабильной задержки. Но в задаче «zero loss + SLA по latency» valkey начинает подтекать: да, не потеряет, но предсказуемость страдает. В оправдание запишем тот факт, что скорее всего, valkey или redis уже будет на проекте как cache.

Кейс 4: Rabbit

Ну вот и добрались до Очереди. Да, именно с большой буквы. Настоящая, взрослая, жирненькая очередь, как у больших дядек в фаанге. "Для очередей придумана!" - это про нее. Все архитекторы дружно кивают головами: durable queue, ack, retry, всё как завещали тебе Фаулер, Хоппе (Хохпе?) и Клишин.

Как работает: – api пишет задачу в durable queue через AMQP. Это не запись в файл напрямую, а запись через брокер, его буферы, его собственный журнал, еще и по сети. – ACK клиенту прилетает сразу после попадания в очередь (и тут уже вопрос: в память или на диск). – Воркер подписан на очередь, получает сообщения, подтверждает через ack, или говорит, что не смог через nack.

Плюсы: – Ack/Nack/retry/маршрутизация из коробки. – At‑least‑once встроен (с оговоркой: гарантируется сохранность сообщения, но не отсутствие дубликатов) – Fanout/headers/топики для сложной топологии.

Минусы: – Latency выше и пила по p99. – Durability условная без durable+persistent+publisher confirm. – Failover через Raft: пауза на выбор лидера, redelivery, без confirm — потеря. – Сложный зоопарк (кластер, HA‑политики, мониторинг), непредсказуемый throughput при пиках.

Несмотря на то, что RabbitMQ выглядит «серьёзным», "большим", "взрослым" и очень нужным,  по факту добавляет: дополнительный hop в pipeline по сети, непредсказуемые задержки и вероятность потерять данные при кривой конфигурации.

Для задач «принять таску и сохранить без потерь» — rabbit не лучше, чем WAL или Ingest. Для задач «маршрутизировать в десять разных консьюмеров с fanout/headers-routing» — норм. Но если тебе это не надо, RabbitMQ — это, уже на теоретической части, оверинжиниринг.

Примерно такой поток мыслей будет в голове у архитектора, который с кофой сидит и думает как будет закрывать SLA. Давай теперь расскажу как и на чем тесты проводились.

Часть третья: Стенд. Что? Где? Когда?

Собрал значит стенд, один репозиторий, 4 сценария. Поднимаем через docker-compose, немного bash скриптов, make.

Окружение у стенда получилось следующее: - Node.js ≥ 22:  api, воркеры, утилиты, клиенты для бд и очередей, самописный WAL - PostgreSQL 16:  основная медленная СУБД и ingest в отдельном контейнере для второго кейса - RabbitMQ 4.1: для четвертого кейса - Генератор нагрузки: autocannon. - Метрики: логи в json для таймингов. - ОС-метрики: telegraf 1.35

Для каждого кейса отдельный api и worker (см. apps/*). – WAL: запись в файл, ротация и воркер, который докатывает сегменты. – Ingest: отдельная БД для приема и воркер, который батчами с ограниченной параллельностью переливает из ingest в main. – Valkey: XADD в stream, чтение через consumer group. – Rabbit: durable очередь по AMQP.

Для Ingest, Valkey, Rabbit использовал готовые клиенты из npm. WAL пришлось написать самому, в npm не оказалось нормальной реализации, есть пара пакетов, один древний, второй сомнительный. Ну и zerodeps как никак. 700 строк и +- рабочий WAL готов, с ротациями, с таймерами, локами и блекджеком.

Долгую запись в основную бд эмулирую через триггер со sleep на запись каждой строки. Нагрузка идёт отдельным сервисом loadgen (autocannon под капотом).

Сценарий нагрузки: RPS: 500. Каждый прогон: 30 с прогрев (1/2 RPS) → 5 мин стабильно RPS → 30 спад (1/2 RPS). Сбои (на 3-й минуте):  Kill воркера на 30с, затем рестарт.

Можно придумать другие сценарии, но не стал, одного считаю достаточным для сравнения в рамках данного изыскания.

По метриками тоже не стал изобретать. Telegraf для os, там все из коробки. По бизнес метрикам json логи в файл. Просто читать и анализировать.

Что собирал:

• durable — время надёжной фиксации в соответствующем стораже:

- WAL: до записи в журнал. - Ingest: до коммита транзакции в ingest-БД. - Rabbit: до получения publisher confirm. - Valkey: задержка XADD; только при appendfsync=always это «сразу durable».

• committed — кол-во строк и время коммита в основную бд
• db_count – кол-во записей в основной бд в момент времени
• backlog – размер хвоста в момент времени
• api_latency – время, за которое ответил api и каким кодом
• OS метрики cpu, mem, diskio, net для контейнеров, участвующих в прогоне (api/worker/сервис).

Для сравнения по каждому кейсу будем считать набор стабильных метрик:

• latency (api, durable, committed) — чтобы видеть, где именно в цепочке появляется задержка; 
• backlog — динамику роста и слива очереди, пик и площадь под кривой, то есть сколько «долга» система накапливает; 
• пропускную способность (committed rps), стабильность и хвостовые индексы (tail index) — насколько тяжёлые редкие задержки по сравнению с медианой; 
• итоговое количество записей (rows_total) — для нормализации этих значений между прогонами разного масштаба. 

В результате получаем сопоставимые профили: видно, как быстро система набирает очередь, с какой скоростью от неё избавляется, какие задержки видны пользователю на API-уровне и насколько стабильны внутренние транзакции.

Пример отчета можно посмотреть тут: comare.md

Так же оценим когнитивную нагрузку для каждого кейса.

Критерии оценки:

• Код: строки собственного кода (API+воркер+реплей/ретраи/метрики).
• Конфиг: число обязательных настроек.
• Failure modes: список типов отказов, о которых нужно помнить.
• Наблюдаемость: минимально достаточный набор метрик/алертов.
• Ранбуки: шаги запуска/восстановления для «упал X».

Каждый пункт от 0 до 5, суммируем и получаем «индекс когнитивки»; чем ниже — тем проще.

В целом никакого рокет сайенс, можно самому при желании потрогать. Перейдем к конкретике.

Часть четвертая: Когнитивная нагрузка

WAL • Код: 5/5. (+- 50 api и worker + 600 реализация). • Конфиг: 1/5 (Путь до рабочей директории, когда и как fsync, когда и как rorate, размер батча). 0 devops • Failure: 3/5 (диск/ротация/fsync). • Наблюдаемость: 3/5 (лаг сегментов, место на диске, скорость докатки). • Ранбуки: 2/5 (перезапуск воркера, зачистка сегментов, квоты на диск).

Сумма: 14/25 - реализация подводит, код, который нужно будет поддерживать, не выкинуть. DevOps: 0 - не нужен.

Ingest • Код:  2/5, ( +-100 api + worker). • Конфиг: 2/5 (Конфиги БД, размер батча, lease_ms) . 1 devops • Failure: 4/5 (вакуум/блоат, гонки за ресурс, ретраи транзакций, тайминги lease). • Наблюдаемость: 3/5 (лаг ingest→main, deadlocks/retries, длительность батчей). • Ранбуки: 3/5 (восстановить сервис, чистки/автовакуум, реплей).

Сумма: 14/25 — средняя  нагрузка, «можно держать в голове». DevOps: 1 - вторая бд на другом сервере

Valkey (Streams + AOF) • Код: 2/5 ( +- 100 api + worker). • Конфиг: 3/5. (Конфигурация Valkey, stream, group, blockMs  claimIdleMs) 2 devops • Failure modes: 5/5 (RAM-утечка на lag, AOF/репликация, PEL/claim, trim-политики). • Наблюдаемость: 4/5 (lag/PEL/maxlen/latency скачет от fsync). • Ранбуки: 4/5 (перевыбор лидера, WAIT/min-replicas-to-write, ручные trim).

Сумма: 18 — высокий индекс, «держать в голове труднее». DevOps: 2  - отдельный "новый" сервис, возможны трудности.

RabbitMQ (Quorum) • Код: 1/5 (+-80 строк api + worker). • Конфиг: 5/5 (users, permissions, exchanges, queues, bindings, policies и тд) 4 DevOps • Failure modes: 5/5 (quorum/confirm, flow control, DLX, poison msg, переизбрания). • Наблюдаемость: 5/5 (queues/channels/consumers/lag/DLQ/flow/memory/disk alarms). • Ранбуки: 5/5 (кластер, политики, шардирование, восстановление, дрейф конфигов).

Сумма: 21 — высокая когнитивка, зоопарк, труднее удержать в голове DevOps: 4  - кластер, конфиги и риски потерь высокие.

В итоге по когнитивке:

• WAL (14/25) — простая эксплуатация, но платишь поддержкой собственного кода.
• Ingest (14/25) — баланс: чуть DevOps, остальное — дисциплина СУБД.
• Valkey (18/25) — «быстро, но дорого в голове»: много тюнинга и аварийных сценариев.
• Rabbit (21/25) — минимум кода у тебя, максимум сложности в инфраструктуре.

Оценка субъективна, попытка переложить на цифры виденье сложности каждого решения. Перейдем к тому, ради чего мы тут все собрались.

Часть пятая: Цифры

SLA (p99 API ≤ 50 мс)

Все четыре кейса выдержали заявленный SLA по входным запросам. Разница в том, насколько уверенно они это делают:

• WAL — минимальные задержки, p99 = 14 мс. Ответы приходят практически мгновенно, так как запрос завершается сразу после записи в локальный журнал.
• RabbitMQ — 23 мс. Здесь есть сетевой hop и подтверждение от брокера, но запас прочности остаётся высоким.
• Ingest — 44 мс, вплотную к верхней границе SLA. Для сценария «50 мс» этого хватает, но зазора на будущее почти нет.
• Valkey — 46 мс, прямо на краю допустимого. Любые пики нагрузки могут выбить его за SLA.

Все четыре решения «держат SLA», но WAL и RabbitMQ имеют запас, Ingest и Valkey балансируют на границе.

Durable latency

Это время до того момента, когда запись гарантированно не потеряется (fsync или confirm).

• WAL — 14 мс, фактически совпадает с API latency. Минимум прослоек = минимум задержки.
• RabbitMQ — 22 мс. Брокер добавляет задержку из-за своей внутренней журнализации и подтверждений.
• Ingest — 44 мс. Всё упирается в транзакцию Postgres, на каждое подтверждение уходит десятки миллисекунд.
• Valkey — 45 мс, почти то же самое: fsync на AOF дороже, чем кажется, и скачет вместе с нагрузкой.

Видно, что «каждая новая прослойка» добавляет десятки миллисекунд к фиксации. WAL выигрывает именно простотой: запись в файл и всё.

Коммиты в основную БД

Тут все варианты упираются в одно «бутылочную горлышко»: медленная основная база, ожидаемо. p99 коммита ~ 12.3 секунд, средний throughput около 16 rps.

• WAL: среднее время ~ 9.8 с. Профиль ровный, вариативность низкая — хорошая предсказуемость.
• Ingest: ~ 11.7 с. Немного хуже WAL, но тоже стабильно.
• Valkey: ~ 11.3 с. Схож с Ingest, чуть быстрее.
• RabbitMQ: выбивается — среднее всего 5.5 с, но при этом хвост тяжёлый, доходит до 12.4 с. Коэффициент вариации самый высокий (0.035), то есть профиль «рваный»: часть задач пролетает быстро, часть задерживается надолго.

Никакая очередь сама по себе не лечит узкое место в базе: throughput одинаковый, разница только в том, насколько предсказуемо сообщение добирается до базы.

Backlog и дренаж

Здесь видно, насколько быстро система накапливает очередь и как справляется с хвостом после сбоя:

• WAL: пик ~ 47k задач, скорость дренажа 353/с, хвост уходит за ~ 133 с. Рабочий, предсказуемый профиль.
• Ingest: чуть больше очередь — 50k, дренаж 362/с, очистка за ~ 138 с. По сути те же цифры, что у WAL.
• Valkey: также 50k в пике, но дренирует медленнее — 327/с, до нуля ~ 152 с. Отставание небольшое, но заметное.
• RabbitMQ: резко выбивается. Очередь раздувается до 88k, скорость дренажа всего 250/с, на полное очищение уходит ~ 353 с.

RabbitMQ тратит больше ресурсов на собственные механизмы и за счёт этого копит самый большой хвост и дренирует его хуже всех. WAL и Ingest — наоборот, разгребают быстрее всего.

Стабильность RPS

Коэффициент вариации показывает, насколько «ровно» система держит нагрузку.

• WAL: CV = 0.004 — почти идеально прямая линия.
• Ingest: CV = 0.003 — ещё ровнее.
• Valkey: CV = 0.026, заметные колебания.
• RabbitMQ: CV = 0.035, самая «пилообразная» динамика.

Чем выше CV, тем чаще будут провалы и скачки нагрузки. Для бизнеса важнее ровный поток — тут выигрывают WAL и Ingest.

Нагрузка на железо

Смотрим на ресурсы контейнеров:

• WAL: worker грузит CPU до 68%, в среднем ~16%. Для single-process нагрузки это нормально.
• Ingest: Postgres-ingest забирает ~9% CPU, пиками до ~32%. Очень умеренно.
• Valkey: CPU потребление невысокое, память в пределах пары гигабайт.
• RabbitMQ: сам брокер в среднем ~19% CPU, но с пиками до 100%. При этом база тоже нагружена.

RabbitMQ на ровном месте создаёт дополнительную нагрузку на CPU, WAL и Ingest в этом плане экономичнее.

Все собранные цифры можно посмотреть тут или самому собрать.

Что в итоге?

По цифрам картинка складывается однозначная:

• WAL и Ingest закрывают SLA и zero-loss с минимальными накладными расходами. Первый вариант даёт мгновенный ответ и предсказуемое поведение ценой поддержки собственного кода. Второй требует отдельной базы и DevOps-дисциплины, но зато использует "привычные" инструменты (бд). В обоих случаях задержка минимальна, профиль ровный, дренаж очереди быстрый.

• Valkey и RabbitMQ тоже справляются с задачей, но делают это хуже: добавляют десятки миллисекунд на ровном месте, сильнее накапливают хвост и дают нестабильный профиль. RabbitMQ особенно выделяется большим backlog и скачущим RPS, а вместе с этим тащит в проект новые точки отказа, дполонительные сложности эксплуатации и накладные расходы.

Из этого следует простой вывод: очередь — не фундамент архитектуры, а специализированный инструмент.

Нужен фан-аут на десятки консьюмеров, маршрутизация по ключам или хитрые сценарии доставки? Тогда Rabbit/Kafka оправданы: они решают задачи иснтументами, которых нет у простого WAL или Ingest.

Нужно просто принять событие и гарантированно не потерять? Файловый журнал или ingest-база справляются проще, быстрее и надёжнее.

Тащить очередь «по умолчанию» — это всё равно что начинать проект сразу с микросервисов в Kubernetes: звучит солидно, но на деле означает больше кода, DevOps шапито, лишняя инфраструктура, больше мониторинга и больше точек отказа.

Очереди нужны не «по умолчанию», а когда без них никак. В остальных случаях — это фетиш, технический долг и лишний костыль, который сам себе суёшь в ...

Что еще почитать?

• Прошлый пост про очереди
• Репо со стендом
• RabbitMQ vs Reddis
• The advantages of queues on logs

Вот ты проектируешь свою систему, базы, микросервисы, кэш - все красиво. И вот встает вопрос: как это все связать, как они будет общаться?

И тут со всех утюгов кричат:

• _У тебя микросервисы - тебе нужны очереди!_
• _Очереди - это модно._
• _Очереди - это полезно._
• _Очереди - это масштаб_ и надежность.
• _Очереди "корпоративный стандарт"._ (как и TS, ага да)

Ты берешь, допустим RabitMQ, поднимаешь брокер (+1 сервис и глобальная точка отказа), и получаешь большую асинхронную боль сквозь всю систему, рост когнитивной нагрузки и эксплуатационные издержки: лаг, дубликаты, краш консумера, ядовитые сообщения и дрейф схем. Да есть и полезное: буферизация, распределение по времени, изоляция сбоев и фан-аут. Но какой ценой?

Если у тебя CRUD между двумя сервисами и одинаковые требования по времени ответа и доступности - очередь только навредит.

Синхронный вызов честно говорит: «_либо сделал, либо нет_». С очередью ты говоришь: «_когда-нибудь, возможно, кто-то где-то это обработает_».

Отсюда вылезают взрослые темы, которые почему-то игнорируют, когда «прикручивают Kafka/Rabbit ради моды»:

• Доставка: at-least-once - дубликаты - идемпотентность на приёмнике
• Порядок: забудь «строгий порядок», у тебя head-of-line blocking или вообще все перемешано.
• Нагрузка: «очередь поможет удержать пик нагрузки» — да, но хвост растёт. Хвост — это твой скрытый долг по времени отклика.
• Мониторинг: трассировка через брокер — это чёрный ящик и пляски с кореляторами.
• Контракты: cобытие — это публичное API. Версионирование, эволюция схем, миграции потребителей — отдельная боль.

Очередь приносит тебе асинхронность как обязательство. А это обязательство принуждает тебя проектировать идемпотентные операции, хранить входящие/исходящие события, жанглировать ретраями и дедупликацией, думать про повторный прогон истории (пересчёт из журнала). Если ты к этому не готов - будет больно, очередь сломает прод, или тебя.

Пример

Сценарий: Создать задачу и отправить ее на исполнение в другой сервис.

Вариант А — MongoDB + outbox (без внешней очереди):

Идея простая: Одной транзакцией пишем задачу и событие. Сервис исполнитель читает события напрямую, делает работу, фиксирует факт обработки. Никакой магии, никаких скрытых механизов доставки, честная атомарность.

// Сервис "Планирователь"
/**
 * @param {import('mongodb').MongoClient} client
 * @param {import('mongodb').Db} db
 * @param {Task} task
 * @returns {{status: boolean, taskId: string}}
 */
export async function createTask (client, db, task) {
  const session = client.startSession()

  try {
    const eventId = crypto.randomUUID()

    session.startTransaction()

    await db.collection('tasks').insertOne(
      {
        _id: task.id,
        type: task.type,
        payload: task.payload,
        status: 'pending',
        createdAt: Date.now()
      },
      { session }
    )

    await db.collection('outbox').insertOne(
      {
        _id: eventId,
        type: 'task.created',
        payload: { taskId: task.id },
        createdAt: Date.now(),
        pickedAt: null,
        doneAt: null
      },
      { session }
    )

    await session.commitTransaction()

    return { status: true, eventId }
  } catch (error) {
    console.error(`[createTask] ${task.id}:`, error)
    await session.abortTransaction()
  } finally {
    await session.endSession()
  }
}

// Сервис "Делатель"
/**
 * @param {import('mongodb').MongoClient} client
 * @param {import('mongodb').Db} db
 * @returns {Promise<void>}
 */
export async function executor (client, db) {
  // атомарно «забронировали» событие
  const event = await db
    .collection('outbox')
    .findOneAndUpdate(
      { type: 'task.created', pickedAt: null },
      { $set: { pickedAt: Date.now() } },
      { sort: { createdAt: 1 }, returnDocument: 'after' }
    )

  if (!event) {
    //нет событий
    delay(100)
    return
  }

  // идемпотентность на уровне обработчика
  const processedId = `${event._id}:executor`
  const processed = await db.collection('processed').findOne({ _id: processedId })

  if (!processed) {
    // уже делали — пропускаем
    return
  }

  const task = await db.collection('tasks').findOne({ _id: event.payload.taskId, status: { $ne: 'done' } })

  if (!task) {
   // таск уже кто-то сделал
    return
  }

  if (task) {
    try {
      // делаем таску, помним про идемпотентность
      await doWork(task)
      await db.collection('processed').insertOne({ _id: processedId, at: Date.now() })
      await db.collection('tasks').updateOne({ _id: task._id }, { $set: { status: 'done' } })
      await db.collection('outbox').updateOne({ _id: event._id }, { $set: { doneAt: Date.now() } })
    } catch (error) {
      // ретраи с backoff, лимит → DLQ
      console.error(`[executor] ${task.id}:`, error)
      await db.collection('outbox').updateOne({ _id: event._id }, { $set: { pickedAt: null } })
      await db.collection('processed').deleteOne({ _id: processedId })
      await delay(100)
    }
  }
}
// executor запускается setInterval или setTimeout выше по архитектуре

В примере важное: Задача и событие родились в одном коммите — значит, не потеряются. Исполнитель читает из той же БД — меньше инфраструктуры, меньше точек отказа. Цена — ты сам хозяин ретраев и DLQ, но это как раз то, что нужно контролировать.

Уже слышу крики: "А как же изоляция, границы, связность, какой "ужос" два сервиса работают с одной бд. Как же Чистая архитектура?!" Нормально, отвечу я, когда два сервиса читают одну БД: один владеет записью и инвариантами, остальные читают только стабильную проекцию/реплику по контракту — вот и вся изоляция. Ну это мы отвлеклись. Продолжим.

Вариант Б — RabbitMQ (внешняя очередь)

Наивно делать «insert в БД и затем publish в Rabbit» нельзя: между этими шагами всегда есть окна потерь/дублей. Значит… сюрприз… всё равно нужен outbox. Просто вместо прямого чтения его, будет «ретранслятор в Rabbit».

// Сервис "Планирователь"
export async function createTask (client, db, task) {
//createTask такой же как и в Варианте А, только меняем немного запись
//...
  await db.collection('outbox').insertOne(
    {
      _id: eventId,
      type: 'task.created',
      payload: { taskId: task.id },
      createdAt: Date.now(),
      pickedAt: null,
      publishedAt: null
    },
    { session }
  )
//...
}

// но тут нам нужен еще relay - штука по доставке события из бд в очередь

/**
 * @param {import('mongodb').Db} db
 * @param {import('amqplib').Channel} rmqChannel
 * @param {string} exchange
 * @returns {Promise<void>}
 */
export async function relay (db, rmqChannel, exchange) {
  const event = await db
    .collection('outbox')
    .findOneAndUpdate(
      { type: 'task.created', pickedAt: null },
      { $set: { pickedAt: Date.now() } },
      { sort: { createdAt: 1 }, returnDocument: 'after' }
    )

  if (!event) {
    await delay(50)
    return
  }

  try {
    await publishConfirm(rmqChannel, exchange, 'task.created', Buffer.from(JSON.stringify(event)))
    await db.collection('outbox').updateOne({ _id: event._id }, { $set: { publishedAt: Date.now() } })
  } catch (e) {
    await db.collection('outbox').updateOne({ _id: event._id }, { $set: { pickedAt: null } })
    await sleep(100)
  }
}

// Сервис "Делатель"
/**
 * @param {import('mongodb').Db} db
 * @param {Object} msg
 */
export async function consumeAndExecute (db, msg) {
  const event = JSON.parse(msg.content.toString())

  // идемпотентность на уровне обработчика
  const processedId = `${event._id}:executor`
  const processed = await db.collection('processed').findOne({ _id: processedId })

  if (!processed) {
    //дубль, уже исполнили
    return 'ack'
  }

  const task = await db.collection('tasks').findOne({ _id: event.payload.taskId, status: { $ne: 'done' } })

  if (!task) {
    return 'ack'
  }

  if (task) {
    try {
      // делаем таску, помним про идемпотентность
      await doWork(task)
      await db.collection('processed').insertOne({ _id: processedId, at: Date.now() })
      await db.collection('tasks').updateOne({ _id: task._id }, { $set: { status: 'done' } })
      return 'ack'
    } catch (error) {
      console.error(`[consumeAndExecute] ${task.id}:`, error)
      // ретраи с backoff, DLX/TTL, лимит → DLQ, можно ответить 'nack' получим еще раз
      await db.collection('processed').deleteOne({ _id: processedId })
      return 'ack'
    }
  }
}

А где минусы спросишь ты. Так вот же, в полтора раза больше кода, больше мест, где, что-то может пойти не так. Дополнительный сервис с брокером. Транспорт между брокером и сервисами. Если не делаешь relay — потеряешь события при падениях между БД и брокером. Если не делаешь inbox и идемпотентность — словишь дубль при redelivery/повторной публикации. Rabbit сам по себе не решает твою бизнес-консистентность, он только перевозит байты.

Внутрисистемный асинхрон: Mongo + outbox закрывает 90% кейсов без зоопарка, и даже фан-аут тоже можно сделать. Но если хочешь фан-аут на внешних потребителей из коробки, независимые группы, интеграции или просто очень хочется очередь — бери Rabbit (или другой брокер), но не забывай: outbox/inbox, idempotency, confirm-публикации, DLQ. Очередь без этих штук — просто дорогая труба с иллюзией надёжности.

Что в итоге?

Очередь — не дефолт. Это тяжёлая зависимость, которая тащит за собой протоколы, идемпотентность, эволюцию схем, эксплуатацию и новые точки отказа.

Нужен буфер? Сделай backpressure и честные 429. Нужна обработка «не в запросе»? Outbox и воркер. Нужен событийный продукт между доменами? И тут все еще можно обойтись без брокера, но уже можно задуматься про него, выбрать, закатать рукава и решиться нырнуть в асинхронный персональный ад.

Не тащи очереди «потому что так делают все». Тащи их, когда без них не сходится модель отказов и нагрузок. Во всех остальных случаях это просто ещё один слой боли.

Хочешь поспорить — покажи, где у тебя backpressure, где идемпотентность и как ты репроцессишь хвост. Если ответ «никак» — очередь тебе не помогла, она просто спрятала проблему в тень.