Когда я захотела больше денег, мне сказали: нарисуй архитектуру приложения
Когда я работала в Райффайзенбанке, в какой-то момент я захотела больше денег. Ну, естественно, мы все хотим больше денег
И мне тогда сказали:
А я такая: ага, класс. Только я в тот момент вообще не понимала, как это делается🧐
И мне пришлось в очень ускоренном темпе разбираться, что такое микросервисы, как они между собой связаны, как вообще это всё рисовать, что важно показать, а что нет
Потому что можно хорошо писать требования, вести встречи, делать документацию, но если ты плаваешь в архитектуре, то на определённом уровне это начинает мешать (и денег не получишь, а в наших реалиях ещё и уволить могут)
💃Собственно, после этого я сама побежала учиться, собирала все с разных источников, но как итог - добилась повышения, а в последствии, это стало моим преимуществом при переходе в другую компанию!
Если сейчас актуально начать изучение архитектуры, то осталось пару часов до конца предпродаж на курсы —
«Архитектура систем. База» — 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
🔥7
📊 Опрос: Архитектура — проверка перед углублением
4 вопроса про декомпозицию, интеграции, документирование и компромиссы. Отвечай в комментариях — разбор сразу после вопроса.
4 вопроса про декомпозицию, интеграции, документирование и компромиссы. Отвечай в комментариях — разбор сразу после вопроса.
Монолит: модуль «Оплата» меняется раз в неделю, «Справочник валют» — раз в год. Команда 7 человек, один релизный цикл. Что логичнее зафиксировать в ТЗ на этап 1?
Anonymous Quiz
13%
Общая БД, но разные репозитории в Git
21%
Сразу два микросервиса — оплата и справочник
43%
Оставить в монолите; вынести оплату только при отдельном SLA и команде
23%
Справочник вынести первым — он проще
❤2
📖 Пояснение:
Граница сервиса оправдана, когда есть независимый жизненный цикл, нагрузка или ограничения (безопасность, compliance). Частые изменения оплаты в монолите из 7 человек не требуют отдельного деплоя — наоборот, дробление усложнит релизы.
Критерии выноса фиксируют в ТЗ заранее — чтобы не «резать ради схемы».
Почему не 1
Разные репозитории при общей БД — худшее из двух миров: связность данных + сложность сборки.
Почему не 2
Два микросервиса при одном релизном цикле = распределённая сложность без выгоды. Синхронные вызовы, отладка, мониторинг — дороже монолита.
Почему не 4
«Проще» — не критерий. Справочник редко меняется; вынос не снимает боль с оплаты.
💡 На собесе: «когда дробить» — про SLA, команду и частоту изменений, не про модули в коде.
Пользователь оформил заказ. Нужно: списать остаток, принять оплату, отправить письмо. Письмо может уйти через 2 минуты. Остаток и оплата — критичны. Как описать интеграции в ТЗ?
Anonymous Quiz
3%
Всё в брокер — пользователь ждёт callback
92%
Остаток и оплата — синхронно в потоке ответа; письмо — в брокер после успеха
2%
Всё синхронно, включая почтовый сервис
3%
Только брокер между всеми тремя шагами
❤2
📖 Пояснение:
Граница sync/async проходит там, где пользователю нужен мгновенный ответ о результате заказа vs где допустима задержка.
▫️ Резерв и оплата — часть транзакции «заказ создан / не создан»
▫️ Письмо — побочный эффект, переживает сбой почты через повтор из очереди
Почему не 1
Callback усложняет фронт и UX. Для оформления заказа пользователь ждёт прямой ответ.
Почему не 3
Синхронная почта блокирует ответ при падении SMTP — заказ «создан», а пользователь видит ошибку.
Почему не 4
Брокер для критичного пути добавляет задержку и согласованность без выгоды.
💡 В ТЗ явно: критичный путь vs фоновые действия.
Заказчик просит «одну схему архитектуры» для разработчиков, безопасности и директора. Что заложить в пакет документации?
Anonymous Quiz
97%
Несколько уровней: контекст для бизнеса, контейнеры для разработки, при необходимости компоненты
2%
Одна детальная схема со всеми классами
1%
Только список технологий в таблице
1%
Диаграмма последовательности на 40 шагов
❤2
📖 Пояснение:
Модель C4 (или аналог) решает конфликт аудиторий:
▫️ Контекст — система и внешние акторы (директор)
▫️ Контейнеры — приложения, БД, брокеры (разработка, безопасность)
▫️ Компоненты — внутри одного контейнера, когда нужна детализация
Одна «мегасхема» не читается ни одной аудиторией.
Почему не 2
Классы — уровень кода, не архитектуры продукта. Устаревает за день.
Почему не 3
Таблица технологий не показывает связи и потоки данных.
Почему не 4
40 шагов — поведение одного сценария, не структура системы.
💡 Аналитик выбирает уровень под вопрос, а не рисует всё сразу.
❤3
Команда спорит: RabbitMQ или Kafka для уведомлений (~500 сообщений/мин). Нужен документ для фиксации выбора. Что оформить?
Anonymous Quiz
3%
Решение зафиксирует разработчик в комментарии к задаче
2%
Устное «берём Kafka, все так делают»
1%
Только ссылка на статью в Confluence
94%
Запись об архитектурном решении: контекст, варианты, выбор, последствия
📖 Пояснение:
ADR (запись об архитектурном решении) — короткий стандартный формат:
▫️ Проблема и контекст (500 уведомлений/мин, команда знает Rabbit)
▫️ Рассмотренные варианты
▫️ Решение и почему не другое
▫️ Последствия (операционка, обучение)
Через год никто не вспомнит «почему Kafka», если не записано.
Почему не 1
Комментарий в задаче теряется; не входит в архитектурную базу знаний.
Почему не 2
«Все так делают» — не аргумент для 500 сообщений/мин. Kafka избыточен без потоковой аналитики.
Почему не 3
Статья без вашего контекста не снимает ответственность команды.
💡 На Middle аналитик умеет инициировать и оформлять ADR.
❤3
Системный анализ | Ольга Пономарева
Почему системному аналитику важно понимать архитектуру Вы заметили, что последнее время на канале появилось множество постов про архитектуру (прям как новостей про бензин сейчас 🫠) 1️⃣ На самом деле, первая причина кроется в том, что по итогам работы с…
Сейчас на собесах много гоняют по архитектуре
Это не просто слова, прогревающие к курсам по архитектуре. Это то, что мне приносят ученики с карьерного сопровождения
Несу частые/повторяющиеся вопросы с собесов по архитектуре:
Если вы хотите расти, проходить собесы на сильные позиции и не теряться в разговорах про интеграции, брокеры, микросервисы и сбои — архитектура всё ещё нужна. Ничего не отменилось!
6 июля стартует обновленный курс "Архитектура. База" - приходите)
Это не просто слова, прогревающие к курсам по архитектуре. Это то, что мне приносят ученики с карьерного сопровождения
И знаете, что меня каждый раз немного веселит? Проходят годы, меняются компании, появляются новые модные слова, ИИ, агенты, Cursor, всё на свете — а на собесах всё равно спрашивают архитектуру!
Несу частые/повторяющиеся вопросы с собесов по архитектуре:
• Расскажи про последнюю большую задачу? Как это было спроектировано, какие протоколы?
• Какие вопросы задаёшь, чтобы выбрать интеграцию?
•Спроектируй позитивный сценарий оплаты + обсуди сбои?
•Глубина по Kafka/Rabbit, отличия, приоритизация чтения?
•Когда выбирать монолит, а когда микросервисы?
•Каким бывает межсервисное взаимодействие (синхрон/асинхрон) и где применяется?
•Как отправлять события просмотров при большой нагрузке?
•Спроектируйте решение по АЗС: экран списка АЗС и детали с видами топлива и ценами.
Если вы хотите расти, проходить собесы на сильные позиции и не теряться в разговорах про интеграции, брокеры, микросервисы и сбои — архитектура всё ещё нужна. Ничего не отменилось!
6 июля стартует обновленный курс "Архитектура. База" - приходите)
❤2🔥2