Финальный урок записан. Мы готовы к ученикам!

Сегодня записала последний урок для курса «Архитектура. База» и наконец-то могу выдохнуть: курс собран и получилось просто бомба! Как обычно объясняю просто даже сложные вещи, такие как балансировщик, вебхуки, вебсоекты и другие страшные слова!

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

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

1 поток стартует уже 6 июля, в понедельник!
До конца июня можно попасть со скидкой 15% по промокоду JUNE15

👉Подробнее о курсе

Успевайте попасть в первый поток😎

«Архитектурные стили: зачем аналитику думать о них до того, как написали первую строчку кода»

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

Это не просто «выбор термина». Это определит, как вы будете разрабатывать, релизить и страдать ближайшие 3–5 лет.


👉 Что важно понять аналитику:

▫️ Монолит — быстрый старт и простой деплой. Но когда команда вырастает, любое изменение тянет 2 недели регресса. Пример: поправили скидку в каталоге — случайно упала оплата.

▫️ Модульный монолит — разбиение внутри одного кода на модули с чёткими интерфейсами. Даёт жёсткие границы, но деплой всё ещё один. Отличный компромисс, пока не упрётесь в масштабирование команды или базы.

▫️ Микросервисная — независимые релизы, изоляция падений, разные технологии. Но ценой сложности сетевых вызовов, распределённых транзакций и необходимости управлять сотнями конфигураций.


👉 Как аналитик влияет на выбор:

▫️ По скорости изменений — если три команды релизят каждый день, нужны микросервисы. Если одна команда и стабильный продукт — берите модульный монолит.

▫️ По данным — если в 90% запросов JOIN по 5 таблицам, микросервисы превратятся в «распределенный монолит» с сетевым оверхедом. Оставляйте монолит.

▫️ По команде (закон Конвея) — система копирует структуру общения. Две команды на 20 сервисов? Вы создаете себе ад с потерянными владельцами и бесконечными созвонами.

▫️ По NFR — платежам нужно 99.99% аптайма, а админке 99.9%. Сервисы позволят изолировать их на разных кластерах. В монолите падение админки уронит оплату.


🚩 Красные флаги для аналитика:

▫️ Проект берет микросервисы, потому что «модно», а не из-за нагрузки или размера команды
▫️ Нарисовали 20 сервисов, но никто не может объяснить, где проходят границы доменов
▫️ Главный антипаттерн — все сервисы пишут в одну общую БД. Это не микросервисы, а монолит с сетевыми задержками. Вы получили все минусы, но ни одного плюса.

💡 На собеседовании Middle+: когда спрашивают «почему выбрали микросервисы», правильный ответ начинается не с технологий, а с ограничений: «Мы выбрали, потому что у нас три команды, которые развивают независимые бизнес-способности, и критично разное время релиза». Выбор архитектуры — всегда компромисс между скоростью разработки и операционной сложностью


Бесплатный вебинар 30 июня 19:00 мск
"Пошаговый гайд по System Design"

Почему системному аналитику важно понимать архитектуру

Вы заметили, что последнее время на канале появилось множество постов про архитектуру (прям как новостей про бензин сейчас 🫠)

1️⃣ На самом деле, первая причина кроется в том, что по итогам работы с учениками в карьерном сопровождении, мы выяснили, что на собесах сейчас очень много гоняют по вопросам архитектуры, и по сути, они являются ключевыми

Поэтому, если вы планируете проходить собесы (а в текущих реалиях лучше к ним точно готовиться), то знания и опыт по архитектуре вам точно пригодятся

2️⃣ Вторая причина связана с тем, что тренд сейчас не только на ИИ и сокращения, но и продолжает развиваться история про "аналитик должен знать архитектуру" в компаниях, и, поэтому, если вы хотите быть ценнее на рынке, расти в зп/должности - то вам точно необходимы знания в архитектуре!

Так что, ждем завтра всех на вебинаре «Пошаговый гайд по System Design»

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

— «Архитектура систем. База» — 6 июля
— «Архитектура систем. Хард» — 27 июля

До конца завтрашнего дня можно приобрести со скидкой 15%

Успевайте приобрести по предпродаже по выгодным условиям!

Apache Kafka 4.0 — что нового для аналитика в мажорном релизе

В марте 2026 года вышел Apache Kafka 4.0 — первый мажорный релиз за последние годы. Kafka давно перестала быть просто «очередью сообщений», а стала платформой потоковой обработки данных. Новый релиз приносит изменения, которые аналитикам стоит знать, даже если они не администрируют кластеры.


👉 Что нового важно для системного аналитика:

▫️ KRaft (Kafka Raft) стал стандартным режимом — Zookeeper окончательно удалён из кодовой базы. Это упрощает архитектуру: не нужно думать о внешней системе координации. Для аналитика — меньше зависимостей в схемах, надёжнее в условиях сетевых разделений.

▫️ Встроенный tiered storage (гибридное хранение) — данные автоматически перемещаются между быстрым SSD и холодным объектным хранилищем. Для аналитика это изменение в НФТ: можно гарантировать большее время хранения логов и событий без пересчёта бюджета на диски. На проекте — дешевле хранить аудит и историю, проще реализовывать replay.

▫️ Поддержка стандартизированного REST API для управления — теперь можно управлять топиками, конфигурациями и ACL через HTTP без дополнительных утилит. Для аналитика, который описывает интеграцию с Kafka в ТЗ — это уточнение в API-контракте: внешние системы могут настраивать доступ через REST, а не только через CLI.

▫️ Улучшенная наблюдаемость (metrics v2) — новые метрики задержек на уровне consumer-группы и топика. Для аналитика — проще формулировать SLI и SLO в нефункциональных требованиях для потоковых интеграций.


👉 Что это значит на проекте:

В ТЗ на интеграцию через Kafka можно опираться на её встроенную наблюдаемость без кастомных сборщиков метрик.

Tiered storage позволяет проектировать системы с долгим хранением событий (например, юридически значимый аудит на 3 года) без переплаты за SSD.

Отказ от Zookeeper делает архитектуру системы проще для новых членов команды — на схемах меньше компонентов.

💡 Для собеседования: если спрашивают «как вы обеспечиваете надёжность событийных интеграций», хороший ответ — описать не только delivery guarantee, но и метрики задержек, и возможности репроцессинга из долгого хранилища в Kafka 4.0. Показывает глубину понимания платформы.

Источник: Apache Kafka 4.0 Release Notes

Меня обняли за видео на YouTube 🥹

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

«Спасибо за ваши видео на YouTube про собеседования. Они помогли мне трудоустроиться несколько лет назад»

И потом просто обнял меня

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

Наверное, именно ради таких моментов я до сих пор записываю ролики, веду канал и запускаю новые курсы ❤️Потому что никогда не знаешь, какой именно пост, видео или совет окажется для кого-то тем самым недостающим кусочком пазла


А уже сегодня в 19:00 (мск), вебинар по теме "Пошаговый гайд по System Design" может тоже изменить вашу жизнь, кто знает 💁‍♀️

📂 Кейс: «Нарисуйте микросервисы» — и проект ушёл в сторону

🏢 Контекст:

Внутренний портал заявок в ИТ, 400 пользователей, монолит на .NET, команда 6 человек. Новый тимлид с опытом маркетплейса попросил аналитика «сразу заложить целевую архитектуру» для презентации руководству.


😬 Проблема:

Аналитик за выходные нарисовал 14 микросервисов, Kafka и отдельный сервис «уведомления». На ревью архитектор спросил: «Где боль? У нас 120 заявок в день и один релиз в две недели». Руководство увидело схему — и решило, что проект «станет в 3 раза дороже».


🔍 Что сделал аналитик после отката:

1. Собрал факты: нагрузка, команда, частота релизов, узкие места монолита (отчёт по SLA — 4 часа в месяц)
2. Предложил поэтапно: сначала вынести отчёты и тяжёлый поиск в отдельный модуль внутри монолита
3. Зафиксировал в документе критерии перехода к микросервисам: отдельный SLA, независимый релизный цикл, команда > 8 человек
4. Нарисовал текущую и целевую схему на горизонте 18 месяцев — без «большого взрыва»


✅ Результат:

Комитет согласовал roadmap. Через 5 месяцев — модуль отчётов с кэшем, без Kafka. Микросервисы остались в плане на фазу 2, когда вырастет нагрузка.


💡 Выводы:

▫️ Схема на 15 блоков без контекста пугает бизнес сильнее, чем помогает
▫️ Аналитик продаёт не технологию, а этапы и критерии перехода
▫️ «Целевая архитектура» ≠ «микросервисы завтра»