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

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

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

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

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

Отрицательная обратная связь это когда система компенсирует отклонения и возвращает состояние к норме. Это стабилизация. 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

5. System design. Забиваем гвозди микроскопом

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

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

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

Рука так и тянется к модному, к «стандартам индустрии». Хочется взять 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. Обратная связь. Если бы мы знали, что это такое, но мы не знаем, что это такое

06. System design. А где конец то?

Всё хорошее и плохое имеет свойство заканчиваться, и я спешу тебя порадовать: мы с тобой добрались до финальной части серии про 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 — чтобы держать руку на пульсе, но не гнаться за каждой волной.

Да, это ещё один инженер с мнением

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

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

Да так, захотелось поделиться, и думаю настало время познакомиться, наконец.

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

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

Я топлю за zero deps подход, наверное, ты уже догадался. Но не только из-за безопасности, нет, это только верхушка. Zero-deps даёт контроль и возможность выжать максимум. Максимальный Performance это то, к чему я стремлюсь. Если что-то сделать можно более эффективно, постараюсь это сделать. 

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

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

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

На данный момент из публичного, это microlike фреймворк поверх uWebSockets, изучаю оверхед, который приносит nodejs и как дорого приходится платить за удобство. 

За эти годы мне довелось поработать с довольно разными системами, от высоконагруженных микросервисов на ноде и realtime сервисов до инфраструктуры, протоколов, автоматизации и продуктовых платформ. Возможно, когда-нибудь смогу рассказать подробнее ;) 

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

Жена, привет, знаю, ты это прочитаешь. Спасибо и тебе, читатель. 

Кушайте кашу и читайте книги. Хейтеры, обнял вас.

Хреновый ты архитектор, zero deps

Привет, читатель, случилась недавно со мной интересная ситуация.

Пришёл ко мне знакомый, назовём его З, от знакомого Л, и говорит: «zero deps тыж программист, а не сможешь ли ты, мне, пожалуйста, сделать ТГ ботика для учёта моего мелкого бизнеса, за денежку».

Кто я такой, чтобы отказать.

Говорю, не вопрос, любой каприз за ваши деньги, давай подробнее: «Что? Как? Зачем? И почему?»

Обсудили, если коротко: хочется ТГ бот учёта движения деняк в гипермалом бизнесе для самоконтроля. Гугл таблицы надоели, данные «открыты», там не синкается, здесь тормозит, там доступ отвалился. С телефона неудобно, нужен бот.

Бюджет не пилим, сошлись на том, что делаю безвозмездно, а там «спасибо» на усмотрение Товарища З.

Минут 20 покумекал и сложилось ТЗ с примерным планом-капканом и стеком.

План простой: берём термос чая, минут 40 ияй собирает пару визардов и пачку клав на grammy для бота и базовый юзкейс. К этому всему прикручиваем Pg с четырьмя табличками. Тратим часик — полтора на рефакторинг говнокода от ияй — и в продакшен. Живое MVP часа за 3 и термос чая.

Заспичил Товарищу З, сошлись во мнении, что нужно с этим переспать.

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

Накидал ТЗ к веб-морде, сижу, гляжу — вырисовывается excel на минималках без куртизанок и блек-джека. Ясно вижу велосипед на костылях. Но помочь человеку хочется.

Заспичил Товарищу З, снова сошлись на том, что нужно переспать.

Лежу, думаю дальше: зачем так сложно, давай развернём селфхостед. Возьмём какой-нибудь миниайо ака S3 или вообще nextcloud, прикрутим туда onlyoffice как редактор. И получим на выходе свой гуглдиск со своим гуглдоком и гуглщитом. Сотрудникам доступы красивые раздадим, будет учёт «практически excell» с блек-джеком и резиновыми куртизанками.

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

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

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

Пожаловался ему, поплакался, что вот у меня дилемма: хочется ботика в тг, а можно веб-морду, а ещё можно селфхостед.

И каких же мне в панамку напихали.

Мудрый Бвана сказал простую вещь: архитектор должен решить первопричину боли.

А первопричина боли товарища — в том, что данные «открыты» и «таблички не синкаются».

Тг бот был сразу отвергнут, безапелляционно, залупа.

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

А в финале было предложено сто процентное решение — excel. Да, тот самый, от мелкомягких, с облаком ихейным.

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

Как-то так.

Читайте книги, ищите первопричину боли и кушайте кашу.

P.S. Все персонажи вымышленные. Все совпадения случайны. Все вероятности невероятны.

А Товарищ З себе ботика в итоге навайбкодил за вечер :)

О пользе отдыха для чукчи

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

Всё началось не так давно, лет шесть назад. Я молодой и амбициозный, готовый работать за еду, прилетаю в приморский город N. Ничего не предвещало беды, но меня берут на работу в небольшой стартап, обещают кормить, учить и немного деняк. Что, может пойти не так? 

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

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

Через пару месяцев начались рабочие задачи. Стало ещё интереснее и веселее. Учёба теперь была в перерывах между решением рабочих задач и сном. Рабочие задачи несли ещё больше новых знаний. Я не знал усталости, я не говорил слов: «не знаю», «не получается», «наверное, я не смогу». На все вопросы и предложения я отвечал: «Сейчас узна́ю», «сейчас изучу», «сейчас придумаю решение», «да, конечно, без проблем, сейчас решим». И это давало свои плоды. Знания и опыт ширились, доход стремительно рос, я развивался как специалист. Но было, одно "но". 

Этим "но" был отдых. Для меня отдыхом было прочитать пяток статей на тему, как что-то написать, или как что-то работает. Отдыхом для меня были попытки придумать и написать для себя: crm, арбитражного бота, сайтик для бронирования уроков по английскому, бесчисленное количество ботов в тг. Я думал, что отдыхаю, когда изучал, как работает браузер, что за зверь такой этот фингерпринт и зачем его собирают. Думал, что мой мозг переключается при работе не с js, а с плюсами, когда я копался в хроме с электроном. Ой, как я ошибался. 

Незаметно для меня пролетели 4 года и пришло оно, выгорание. Ой, ты, читатель, наверное, сейчас начнёшь в меня кидаться говной и кричать, о блет ещё один псевдоразрабочик, типа заебался и выгорел, нытик блет. Ну я в целом тоже так думал. Какое нахер выгорание, тебе ещё 30 нет, ты здоровый молодой, парень, тебе ебашить и ебашить! Ну как бы да, но и не то чтобы нет. 

События помимо работы тоже оставляли свой след. Помимо того, что ты ебашишь 24/7, так тебе ещё пиздюлей ментальных, моральных, а иногда ещё и физических старается навесить окружающий мир. Это тоже давало свои плоды. Кукуха решила сказать «Адьес» и ебануть во все стороны, как твой кот, перед тем как сходить посрать. 

Ну вот примерно тут я попробовал уйти с текущей работы и плотно заняться собой, здоровьем, кукухой и попробовать отдохнуть. Но и тут, что-то пошло не так. Меня купили, мне предложили неприлично много, и я не смог отказаться. Спасибо моей Жене, которая в тот момент пришла и ультимативно заявила, что хватит это терпеть, тебя тяжело вывозить с твоей кукухой. Ты пиздуешь к психологу, ты ебашишь в зал с тренером и ты, мать твою, делаешь себе хотя бы один выходной в неделю, пидр!

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

Вот уже два года чукча, в лице вашего автора @zerodeps, учится отдыхать. Это оказалось не так-то просто. Это оказалось ппц непросто. Казалось бы, забей хуй, валяйся и читай книгу, ходи по улице или в компьютер поиграй. Но нет, мой коварный мозг постоянно вставляет палки в колёса и пытается навязать мне разные чувства. От мысли, что ты бездарный бездельник, потому что уже 5 минут не проверял рабочий чат, до чувства дичайшего дискомфорта, когда у тебя в грёбаном нигде посреди леса пропадает связь и ты не можешь загрузить чаты в тг. Ещё есть чувство упущенных возможностей, это вообще отдельная тема. Таких примеров я могу привести, наверное, десятки, если не сотни. Возможно, когда-нибудь напишу об этом подробнее. 

Два года учусь отдыхать, переключаться и посылать этот мир на хер. Это повышает мой кпд, делает мою работу приятнее. С каждым днём у меня получается отдыхать чуточку лучше. Чего и вам советую ;)

Отдыхайте, кушайте кашу и иногда не читайте книги!

О том как Чукча свой путь ходит

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

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

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

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

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

Как раз подошёл к завершению час ходьбы, спасибо, что читаете.

Как-то так.

Кушайте кашу, ходите и читайте книги

Объекты в JS не бесплатные

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 сохранится, движок не потеряет в оптимизации.