«Архитектурные стили: зачем аналитику думать о них до того, как написали первую строчку кода»
Когда команда начинает проект, первый вопрос, который должен решить аналитик: в каком архитектурном стиле мы будем строить систему? Монолит, модульный монолит или чистая микросервисная архитектура?
Это не просто «выбор термина». Это определит, как вы будете разрабатывать, релизить и страдать ближайшие 3–5 лет.
👉 Что важно понять аналитику:
▫️ Монолит — быстрый старт и простой деплой. Но когда команда вырастает, любое изменение тянет 2 недели регресса. Пример: поправили скидку в каталоге — случайно упала оплата.
▫️ Модульный монолит — разбиение внутри одного кода на модули с чёткими интерфейсами. Даёт жёсткие границы, но деплой всё ещё один. Отличный компромисс, пока не упрётесь в масштабирование команды или базы.
▫️ Микросервисная — независимые релизы, изоляция падений, разные технологии. Но ценой сложности сетевых вызовов, распределённых транзакций и необходимости управлять сотнями конфигураций.
👉 Как аналитик влияет на выбор:
▫️ По скорости изменений — если три команды релизят каждый день, нужны микросервисы. Если одна команда и стабильный продукт — берите модульный монолит.
▫️ По данным — если в 90% запросов JOIN по 5 таблицам, микросервисы превратятся в «распределенный монолит» с сетевым оверхедом. Оставляйте монолит.
▫️ По команде (закон Конвея) — система копирует структуру общения. Две команды на 20 сервисов? Вы создаете себе ад с потерянными владельцами и бесконечными созвонами.
▫️ По NFR — платежам нужно 99.99% аптайма, а админке 99.9%. Сервисы позволят изолировать их на разных кластерах. В монолите падение админки уронит оплату.
🚩 Красные флаги для аналитика:
▫️ Проект берет микросервисы, потому что «модно», а не из-за нагрузки или размера команды
▫️ Нарисовали 20 сервисов, но никто не может объяснить, где проходят границы доменов
▫️ Главный антипаттерн — все сервисы пишут в одну общую БД. Это не микросервисы, а монолит с сетевыми задержками. Вы получили все минусы, но ни одного плюса.
💡 На собеседовании Middle+: когда спрашивают «почему выбрали микросервисы», правильный ответ начинается не с технологий, а с ограничений: «Мы выбрали, потому что у нас три команды, которые развивают независимые бизнес-способности, и критично разное время релиза». Выбор архитектуры — всегда компромисс между скоростью разработки и операционной сложностью
Бесплатный вебинар 30 июня 19:00 мск
"Пошаговый гайд по System Design"
Когда команда начинает проект, первый вопрос, который должен решить аналитик: в каком архитектурном стиле мы будем строить систему? Монолит, модульный монолит или чистая микросервисная архитектура?
Это не просто «выбор термина». Это определит, как вы будете разрабатывать, релизить и страдать ближайшие 3–5 лет.
👉 Что важно понять аналитику:
▫️ Монолит — быстрый старт и простой деплой. Но когда команда вырастает, любое изменение тянет 2 недели регресса. Пример: поправили скидку в каталоге — случайно упала оплата.
▫️ Модульный монолит — разбиение внутри одного кода на модули с чёткими интерфейсами. Даёт жёсткие границы, но деплой всё ещё один. Отличный компромисс, пока не упрётесь в масштабирование команды или базы.
▫️ Микросервисная — независимые релизы, изоляция падений, разные технологии. Но ценой сложности сетевых вызовов, распределённых транзакций и необходимости управлять сотнями конфигураций.
👉 Как аналитик влияет на выбор:
▫️ По скорости изменений — если три команды релизят каждый день, нужны микросервисы. Если одна команда и стабильный продукт — берите модульный монолит.
▫️ По данным — если в 90% запросов JOIN по 5 таблицам, микросервисы превратятся в «распределенный монолит» с сетевым оверхедом. Оставляйте монолит.
▫️ По команде (закон Конвея) — система копирует структуру общения. Две команды на 20 сервисов? Вы создаете себе ад с потерянными владельцами и бесконечными созвонами.
▫️ По NFR — платежам нужно 99.99% аптайма, а админке 99.9%. Сервисы позволят изолировать их на разных кластерах. В монолите падение админки уронит оплату.
🚩 Красные флаги для аналитика:
▫️ Проект берет микросервисы, потому что «модно», а не из-за нагрузки или размера команды
▫️ Нарисовали 20 сервисов, но никто не может объяснить, где проходят границы доменов
▫️ Главный антипаттерн — все сервисы пишут в одну общую БД. Это не микросервисы, а монолит с сетевыми задержками. Вы получили все минусы, но ни одного плюса.
💡 На собеседовании Middle+: когда спрашивают «почему выбрали микросервисы», правильный ответ начинается не с технологий, а с ограничений: «Мы выбрали, потому что у нас три команды, которые развивают независимые бизнес-способности, и критично разное время релиза». Выбор архитектуры — всегда компромисс между скоростью разработки и операционной сложностью
Бесплатный вебинар 30 июня 19:00 мск
"Пошаговый гайд по System Design"
❤9
Почему системному аналитику важно понимать архитектуру
Вы заметили, что последнее время на канале появилось множество постов про архитектуру (прям как новостей про бензин сейчас 🫠)
1️⃣ На самом деле, первая причина кроется в том, что по итогам работы с учениками в карьерном сопровождении, мы выяснили, что на собесах сейчас очень много гоняют по вопросам архитектуры, и по сути, они являются ключевыми
Поэтому, если вы планируете проходить собесы (а в текущих реалиях лучше к ним точно готовиться), то знания и опыт по архитектуре вам точно пригодятся
2️⃣ Вторая причина связана с тем, что тренд сейчас не только на ИИ и сокращения, но и продолжает развиваться история про "аналитик должен знать архитектуру" в компаниях, и, поэтому, если вы хотите быть ценнее на рынке, расти в зп/должности - то вам точно необходимы знания в архитектуре!
Так что, ждем завтра всех на вебинаре «Пошаговый гайд по System Design»
А если хотите глубже разобраться, получить практику и обратную связь, то ждем на курсах:
— «Архитектура систем. База» — 6 июля
— «Архитектура систем. Хард» — 27 июля
До конца завтрашнего дня можно приобрести со скидкой 15%
Успевайте приобрести по предпродаже по выгодным условиям!
Вы заметили, что последнее время на канале появилось множество постов про архитектуру (прям как новостей про бензин сейчас 🫠)
1️⃣ На самом деле, первая причина кроется в том, что по итогам работы с учениками в карьерном сопровождении, мы выяснили, что на собесах сейчас очень много гоняют по вопросам архитектуры, и по сути, они являются ключевыми
Поэтому, если вы планируете проходить собесы (а в текущих реалиях лучше к ним точно готовиться), то знания и опыт по архитектуре вам точно пригодятся
2️⃣ Вторая причина связана с тем, что тренд сейчас не только на ИИ и сокращения, но и продолжает развиваться история про "аналитик должен знать архитектуру" в компаниях, и, поэтому, если вы хотите быть ценнее на рынке, расти в зп/должности - то вам точно необходимы знания в архитектуре!
Так что, ждем завтра всех на вебинаре «Пошаговый гайд по System Design»
А если хотите глубже разобраться, получить практику и обратную связь, то ждем на курсах:
— «Архитектура систем. База» — 6 июля
— «Архитектура систем. Хард» — 27 июля
До конца завтрашнего дня можно приобрести со скидкой 15%
Успевайте приобрести по предпродаже по выгодным условиям!
❤1
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
В марте 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
❤6👍6
Меня обняли за видео на YouTube 🥹
На ЛАФе произошла история, от которой я немного зависла. Вечером после основной программы сидели, общались, обсуждали работу, карьеру, аналитику, болтали и один парень вдруг сказал:
И потом просто обнял меня
Я такие видео записала, выложила и давно пошла дальше. А человек несколько лет назад посмотрел их, лучше подготовился к собесу и нашёл работу. И вот тут меня накрыло: блин, это же не просто контент. Это реально может повлиять на чью-то карьеру, уверенность и жизнь.
Наверное, именно ради таких моментов я до сих пор записываю ролики, веду канал и запускаю новые курсы ❤️Потому что никогда не знаешь, какой именно пост, видео или совет окажется для кого-то тем самым недостающим кусочком пазла
А уже сегодня в 19:00 (мск), вебинар по теме "Пошаговый гайд по System Design" может тоже изменить вашу жизнь, кто знает 💁♀️
На ЛАФе произошла история, от которой я немного зависла. Вечером после основной программы сидели, общались, обсуждали работу, карьеру, аналитику, болтали и один парень вдруг сказал:
«Спасибо за ваши видео на YouTube про собеседования. Они помогли мне трудоустроиться несколько лет назад»
И потом просто обнял меня
Я такие видео записала, выложила и давно пошла дальше. А человек несколько лет назад посмотрел их, лучше подготовился к собесу и нашёл работу. И вот тут меня накрыло: блин, это же не просто контент. Это реально может повлиять на чью-то карьеру, уверенность и жизнь.
Наверное, именно ради таких моментов я до сих пор записываю ролики, веду канал и запускаю новые курсы ❤️Потому что никогда не знаешь, какой именно пост, видео или совет окажется для кого-то тем самым недостающим кусочком пазла
А уже сегодня в 19:00 (мск), вебинар по теме "Пошаговый гайд по System Design" может тоже изменить вашу жизнь, кто знает 💁♀️
❤20👍2🎉1💯1
Когда я захотела больше денег, мне сказали: нарисуй архитектуру приложения
Когда я работала в Райффайзенбанке, в какой-то момент я захотела больше денег. Ну, естественно, мы все хотим больше денег
И мне тогда сказали:
А я такая: ага, класс. Только я в тот момент вообще не понимала, как это делается🧐
И мне пришлось в очень ускоренном темпе разбираться, что такое микросервисы, как они между собой связаны, как вообще это всё рисовать, что важно показать, а что нет
Потому что можно хорошо писать требования, вести встречи, делать документацию, но если ты плаваешь в архитектуре, то на определённом уровне это начинает мешать (и денег не получишь, а в наших реалиях ещё и уволить могут)
💃Собственно, после этого я сама побежала учиться, собирала все с разных источников, но как итог - добилась повышения, а в последствии, это стало моим преимуществом при переходе в другую компанию!
Если сейчас актуально начать изучение архитектуры, то осталось пару часов до конца предпродаж на курсы —
«Архитектура систем. База» — 6 июля
«Архитектура систем. Хард» — 27 июля
До конца дня можно приобрести со скидкой 15%
Успевайте приобрести по предпродаже по выгодным условиям!
Когда я работала в Райффайзенбанке, в какой-то момент я захотела больше денег. Ну, естественно, мы все хотим больше денег
И мне тогда сказали:
«Оль, нарисуй архитектуру всего приложения»
А я такая: ага, класс. Только я в тот момент вообще не понимала, как это делается
И мне пришлось в очень ускоренном темпе разбираться, что такое микросервисы, как они между собой связаны, как вообще это всё рисовать, что важно показать, а что нет
И вот тогда я прям очень хорошо поняла, что архитектура — это не какая-то дополнительная тема «для самых умных». Это то, что в какой-то момент от тебя начинают ожидать, особенно если ты хочешь расти и претендовать на повышение
Потому что можно хорошо писать требования, вести встречи, делать документацию, но если ты плаваешь в архитектуре, то на определённом уровне это начинает мешать (и денег не получишь, а в наших реалиях ещё и уволить могут)
💃Собственно, после этого я сама побежала учиться, собирала все с разных источников, но как итог - добилась повышения, а в последствии, это стало моим преимуществом при переходе в другую компанию!
Если сейчас актуально начать изучение архитектуры, то осталось пару часов до конца предпродаж на курсы —
«Архитектура систем. База» — 6 июля
«Архитектура систем. Хард» — 27 июля
До конца дня можно приобрести со скидкой 15%
Успевайте приобрести по предпродаже по выгодным условиям!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤1
📂 Кейс: «Нарисуйте микросервисы» — и проект ушёл в сторону
🏢 Контекст:
Внутренний портал заявок в ИТ, 400 пользователей, монолит на .NET, команда 6 человек. Новый тимлид с опытом маркетплейса попросил аналитика «сразу заложить целевую архитектуру» для презентации руководству.
😬 Проблема:
Аналитик за выходные нарисовал 14 микросервисов, Kafka и отдельный сервис «уведомления». На ревью архитектор спросил: «Где боль? У нас 120 заявок в день и один релиз в две недели». Руководство увидело схему — и решило, что проект «станет в 3 раза дороже».
🔍 Что сделал аналитик после отката:
1. Собрал факты: нагрузка, команда, частота релизов, узкие места монолита (отчёт по SLA — 4 часа в месяц)
2. Предложил поэтапно: сначала вынести отчёты и тяжёлый поиск в отдельный модуль внутри монолита
3. Зафиксировал в документе критерии перехода к микросервисам: отдельный SLA, независимый релизный цикл, команда > 8 человек
4. Нарисовал текущую и целевую схему на горизонте 18 месяцев — без «большого взрыва»
✅ Результат:
Комитет согласовал roadmap. Через 5 месяцев — модуль отчётов с кэшем, без Kafka. Микросервисы остались в плане на фазу 2, когда вырастет нагрузка.
💡 Выводы:
▫️ Схема на 15 блоков без контекста пугает бизнес сильнее, чем помогает
▫️ Аналитик продаёт не технологию, а этапы и критерии перехода
▫️ «Целевая архитектура» ≠ «микросервисы завтра»
🏢 Контекст:
Внутренний портал заявок в ИТ, 400 пользователей, монолит на .NET, команда 6 человек. Новый тимлид с опытом маркетплейса попросил аналитика «сразу заложить целевую архитектуру» для презентации руководству.
😬 Проблема:
Аналитик за выходные нарисовал 14 микросервисов, Kafka и отдельный сервис «уведомления». На ревью архитектор спросил: «Где боль? У нас 120 заявок в день и один релиз в две недели». Руководство увидело схему — и решило, что проект «станет в 3 раза дороже».
🔍 Что сделал аналитик после отката:
1. Собрал факты: нагрузка, команда, частота релизов, узкие места монолита (отчёт по SLA — 4 часа в месяц)
2. Предложил поэтапно: сначала вынести отчёты и тяжёлый поиск в отдельный модуль внутри монолита
3. Зафиксировал в документе критерии перехода к микросервисам: отдельный SLA, независимый релизный цикл, команда > 8 человек
4. Нарисовал текущую и целевую схему на горизонте 18 месяцев — без «большого взрыва»
✅ Результат:
Комитет согласовал roadmap. Через 5 месяцев — модуль отчётов с кэшем, без Kafka. Микросервисы остались в плане на фазу 2, когда вырастет нагрузка.
💡 Выводы:
▫️ Схема на 15 блоков без контекста пугает бизнес сильнее, чем помогает
▫️ Аналитик продаёт не технологию, а этапы и критерии перехода
▫️ «Целевая архитектура» ≠ «микросервисы завтра»
❤2🔥2
Запись вебинара готова!
Если по какой-то причине вам не удалось на него попасть или планируете пересмотреть, то сделали для вас запись
Доступ до 5 июля включительно!
🤩 СМОТРЕТЬ ЗАПИСЬ: https://school.systemanalyst.life/abkhiz
«Пошаговый гайд по System Design», который прошел 30 июня в 19:00 мск
Если по какой-то причине вам не удалось на него попасть или планируете пересмотреть, то сделали для вас запись
Доступ до 5 июля включительно!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
📊 Опрос: Архитектура — проверка перед углублением
4 вопроса про декомпозицию, интеграции, документирование и компромиссы. Отвечай в комментариях — разбор сразу после вопроса.
4 вопроса про декомпозицию, интеграции, документирование и компромиссы. Отвечай в комментариях — разбор сразу после вопроса.
Монолит: модуль «Оплата» меняется раз в неделю, «Справочник валют» — раз в год. Команда 7 человек, один релизный цикл. Что логичнее зафиксировать в ТЗ на этап 1?
Anonymous Quiz
13%
Общая БД, но разные репозитории в Git
23%
Сразу два микросервиса — оплата и справочник
42%
Оставить в монолите; вынести оплату только при отдельном SLA и команде
22%
Справочник вынести первым — он проще
❤1
📖 Пояснение:
Граница сервиса оправдана, когда есть независимый жизненный цикл, нагрузка или ограничения (безопасность, compliance). Частые изменения оплаты в монолите из 7 человек не требуют отдельного деплоя — наоборот, дробление усложнит релизы.
Критерии выноса фиксируют в ТЗ заранее — чтобы не «резать ради схемы».
Почему не 1
Разные репозитории при общей БД — худшее из двух миров: связность данных + сложность сборки.
Почему не 2
Два микросервиса при одном релизном цикле = распределённая сложность без выгоды. Синхронные вызовы, отладка, мониторинг — дороже монолита.
Почему не 4
«Проще» — не критерий. Справочник редко меняется; вынос не снимает боль с оплаты.
💡 На собесе: «когда дробить» — про SLA, команду и частоту изменений, не про модули в коде.
Пользователь оформил заказ. Нужно: списать остаток, принять оплату, отправить письмо. Письмо может уйти через 2 минуты. Остаток и оплата — критичны. Как описать интеграции в ТЗ?
Anonymous Quiz
3%
Всё в брокер — пользователь ждёт callback
93%
Остаток и оплата — синхронно в потоке ответа; письмо — в брокер после успеха
2%
Всё синхронно, включая почтовый сервис
3%
Только брокер между всеми тремя шагами
❤1
📖 Пояснение:
Граница sync/async проходит там, где пользователю нужен мгновенный ответ о результате заказа vs где допустима задержка.
▫️ Резерв и оплата — часть транзакции «заказ создан / не создан»
▫️ Письмо — побочный эффект, переживает сбой почты через повтор из очереди
Почему не 1
Callback усложняет фронт и UX. Для оформления заказа пользователь ждёт прямой ответ.
Почему не 3
Синхронная почта блокирует ответ при падении SMTP — заказ «создан», а пользователь видит ошибку.
Почему не 4
Брокер для критичного пути добавляет задержку и согласованность без выгоды.
💡 В ТЗ явно: критичный путь vs фоновые действия.
Заказчик просит «одну схему архитектуры» для разработчиков, безопасности и директора. Что заложить в пакет документации?
Anonymous Quiz
96%
Несколько уровней: контекст для бизнеса, контейнеры для разработки, при необходимости компоненты
2%
Одна детальная схема со всеми классами
1%
Только список технологий в таблице
1%
Диаграмма последовательности на 40 шагов
❤1
📖 Пояснение:
Модель C4 (или аналог) решает конфликт аудиторий:
▫️ Контекст — система и внешние акторы (директор)
▫️ Контейнеры — приложения, БД, брокеры (разработка, безопасность)
▫️ Компоненты — внутри одного контейнера, когда нужна детализация
Одна «мегасхема» не читается ни одной аудиторией.
Почему не 2
Классы — уровень кода, не архитектуры продукта. Устаревает за день.
Почему не 3
Таблица технологий не показывает связи и потоки данных.
Почему не 4
40 шагов — поведение одного сценария, не структура системы.
💡 Аналитик выбирает уровень под вопрос, а не рисует всё сразу.
❤2
Команда спорит: RabbitMQ или Kafka для уведомлений (~500 сообщений/мин). Нужен документ для фиксации выбора. Что оформить?
Anonymous Quiz
3%
Решение зафиксирует разработчик в комментарии к задаче
2%
Устное «берём Kafka, все так делают»
1%
Только ссылка на статью в Confluence
95%
Запись об архитектурном решении: контекст, варианты, выбор, последствия
📖 Пояснение:
ADR (запись об архитектурном решении) — короткий стандартный формат:
▫️ Проблема и контекст (500 уведомлений/мин, команда знает Rabbit)
▫️ Рассмотренные варианты
▫️ Решение и почему не другое
▫️ Последствия (операционка, обучение)
Через год никто не вспомнит «почему Kafka», если не записано.
Почему не 1
Комментарий в задаче теряется; не входит в архитектурную базу знаний.
Почему не 2
«Все так делают» — не аргумент для 500 сообщений/мин. Kafka избыточен без потоковой аналитики.
Почему не 3
Статья без вашего контекста не снимает ответственность команды.
💡 На Middle аналитик умеет инициировать и оформлять ADR.
❤2
Системный анализ | Ольга Пономарева
Почему системному аналитику важно понимать архитектуру Вы заметили, что последнее время на канале появилось множество постов про архитектуру (прям как новостей про бензин сейчас 🫠) 1️⃣ На самом деле, первая причина кроется в том, что по итогам работы с…
Сейчас на собесах много гоняют по архитектуре
Это не просто слова, прогревающие к курсам по архитектуре. Это то, что мне приносят ученики с карьерного сопровождения
Несу частые/повторяющиеся вопросы с собесов по архитектуре:
Если вы хотите расти, проходить собесы на сильные позиции и не теряться в разговорах про интеграции, брокеры, микросервисы и сбои — архитектура всё ещё нужна. Ничего не отменилось!
6 июля стартует обновленный курс "Архитектура. База" - приходите)
Это не просто слова, прогревающие к курсам по архитектуре. Это то, что мне приносят ученики с карьерного сопровождения
И знаете, что меня каждый раз немного веселит? Проходят годы, меняются компании, появляются новые модные слова, ИИ, агенты, Cursor, всё на свете — а на собесах всё равно спрашивают архитектуру!
Несу частые/повторяющиеся вопросы с собесов по архитектуре:
• Расскажи про последнюю большую задачу? Как это было спроектировано, какие протоколы?
• Какие вопросы задаёшь, чтобы выбрать интеграцию?
•Спроектируй позитивный сценарий оплаты + обсуди сбои?
•Глубина по Kafka/Rabbit, отличия, приоритизация чтения?
•Когда выбирать монолит, а когда микросервисы?
•Каким бывает межсервисное взаимодействие (синхрон/асинхрон) и где применяется?
•Как отправлять события просмотров при большой нагрузке?
•Спроектируйте решение по АЗС: экран списка АЗС и детали с видами топлива и ценами.
Если вы хотите расти, проходить собесы на сильные позиции и не теряться в разговорах про интеграции, брокеры, микросервисы и сбои — архитектура всё ещё нужна. Ничего не отменилось!
6 июля стартует обновленный курс "Архитектура. База" - приходите)
❤1🔥1