Вначале, наверное, каждый попадал в эту ловушку на собеседовании: кандидат открывает экран, уверенно запускает draw.io и бодро начинает рисовать. Бац — микросервисы! Бац — брокеры сообщений между ними! Redis-кеш сверху, базы данных снизу. Даже стрелки вызовов нарисованы в правильном стиле. Интервьюер кивает, видя техническую беглость. Кандидат чувствует уверенность, ждёт похвалы.
— Отлично, — говорит интервьюер, — а откуда берутся данные для этого отчёта?
Кандидат на секунду замешкается. «Откуда?.. Ах да, из базы данных, наверное... или из очереди?..» Он смотрит на схему, где слева — пустое место перед микросервисами.
— И кто потребитель этого события? — продолжает интервьюер. — Кто его забирает и что делает с результатом?
Кандидат начинает водить курсором по доске draw.io, но схема рассыпается. Сквозного потока данных нет, потому что контекст не был зафиксирован с самого начала. Это не техническая ошибка, а фундаментальный пробел в системном мышлении.
Проблема не в отсутствии знаний, а в отсутствии целостной картины.
Большинство кандидатов (и не только на собеседованиях) сразу ныряет в глубину технологий, не очертив границы системы. Они рисуют внутреннюю механику бэкенда, не уточнив, откуда приходят входные данные и куда уходит результат. Это как строить фундамент, не зная размеров участка. Или как инженер, который начинает проектировать двигатель, не узнав, что это за транспорт и что он должен делать.
На собеседовании такая ошибка критична. Интервьюер видит технический кругозор, но не видит системного мышления. А ведь это именно то, что отличает senior-архитектора от middle, который умеет только пилить отдельные сервисы.
Из этой боли и сформировался фреймворк «Архитектурный крест».
Это не замена для C4 или UML, у меня нет никаких претензий на академичность. Это прикладной инструмент, который я использую на собеседованиях и в реальной работе. Он дисциплинирует мышление и заставляет начать с ответов на три главных вопроса:
Откуда данные? (источники слева)
Куда они идут? (потребители справа)
Какие у нас планы? (AS IS против TO BE)
Этот метод позволяет за пять минут выстроить скелет системы, который демонстрирует интервьюеру зрелость подхода. Ты показываешь не знание конкретных технологий, а понимание природы систем: как они рождаются, функционируют и эволюционируют.
Схема «Архитектурного креста» — это то самое первое впечатление, которое вы можете произвести на собеседовании. Когда интервьюер видит трёхмерную проекцию системы, где пересекаются поток ценности, слои архитектуры и будущие миграции, он мгновенно считывает: «Этот кандидат видит картину целиком. Он не рисует микросервисы ради микросервисов. Он думает о системе как о живом организме с входами, выходами и развитием во времени».
Описание фреймворка
Вообще, «крест» в названии здесь является графической схемой, следуя которой можно быстро и достаточно точно смоделировать систему. И этот крест представляет собой пересечение трех осей:
Горизонтальная ось (X): от источника до потребителя — «Поток данных»
Это главная ось, вдоль которой течёт бизнес-ценность в ИТ — данные и информация. Слева на холсте отображаем их источники. Не абстрактные «источники данных», а конкретные системы, от которых зависит вся цепочка. Впрочем, в качестве источников могут выступать и ручные операции — ввод пользователями данных в интерфейсе или загрузка файлов. Также сюда можно отнести всякие сенсоры с датчиками IoT, партнёрские системы и всё что угодно.
Вот расширенный (но не исчерпывающий) список источников, который я использую на собеседованиях:
Пользовательские действия в интерфейсе: — клики по кнопкам, свайпы в мобильном приложении, ввод форм, голосовые команды.
Файловая загрузка: Excel-файлы для импорта, CSV-списки, PDF-документы для обработки OCR.
Внешние API партнёров и очереди сообщений: вебхуки и вызовы API от внешних систем. Также важно не забыть про асинхронные события (Kafka, Rabbit и так далее).
IoT-сенсоры и устройства: считывание QR-меток на складе, датчики температуры в холодильных камерах, камеры наблюдения. Они генерируют потоки данных без человеческого вмешательства.
Потоки изменений из смежной БД (CDC): Change Data Capture. Когда вместо ежедневной миграции данных ты читаешь журнал MySQL/PostgreSQL и транслируешь изменения в реальном времени.
Справа отображаем наших дорогих потребителей, ради которых всё затевалось. Если информация не доходит до потребителя, то это не архитектура, а игра в кубики:
Фронт пользователя: отображение на экране (товар в корзине, статус заказа, карта доставки). То есть любые выводы в интерфейсе у пользователей системы.
Вызовы бэка других систем: отправка событий и вызовов во внешние и внутренние backend-системы через API, gRPC и тому подобное.
Сообщения в очереди: отправка сообщений в асинхронные очереди (Kafka, RabbitMQ и тому подобные).
Физические устройства: печать чека на кассе, табло на производстве, светодиодная панель на складе с индикацией собранного заказа.
Примечание: если правая часть Креста пуста — это значит, что не проработаны вопросы с потребителями данных.
Горизонтальная ось — это кровеносная система. Данные должны течь от источника к потребителю, без застоев и разрывов. Если ты видишь участок, где поток прерывается — это знак, что ты что-то упустил.
Вертикальная ось (Y): классические слои — «Скелет»
Теперь поговорим о вертикали. Здесь все знакомо: Frontend, Backend, Data. Всем знакомая трёхслойная архитектура.
Важно: это не подробная архитектура с компонентами и портами, а высокоуровневые слои для первичного наброска. На собеседовании они нужны, чтобы показать понимание разделения ответственности, а не засорять доску деталями. Можно вначале обозначить их тремя квадратами, а чуть позже разделить на модули.
Frontend: все виды интерфейса. В дальнейшем делится по функциям — например, «Три интерфейса: мобильное приложение для клиента, веб-консоль для администратора, мобильное приложение для курьера».
Backend: внутренняя часть серверной системы, где происходит обработка данных (API, бизнес-правила, оркестрация). Вначале это один блок, потом раскладывается на микросервисы.
Data: базы данных, кеш, хранилища. Также делим по функциям в зависимости от сценария.
Ключевое взаимодействие осей: данные протекают не просто вертикально (кликнул — ушло в API — сохранилось в БД), а, скорее, диагонально, с учётом тракта распространения. Событие от источника проходит так: интерфейс (Front) → API-шлюз (Back) → база (Data) + выход наружу потребителю. Крест позволяет отследить эту цепочку целиком.
Наконец, добавим третью ось. На плоскости это уже отобразить затруднительно, поэтому подключим воображение. Все-таки, описываемый шаблон — это сначала инструмент мышления, а уже потом — визуализации. Третья ось даст нам пересечение трех отрезков, наподобие системы координат. Или противотанкового ежа. Где-то в параллельной вселенной эта статья могла бы называться «Архитектурный ёж» :)
Ось глубины (Z): настоящее против будущего — «Машина времени»
Это самый сильный и дифференцирующий этап. На нём разворачивается большая часть архитектурных дискуссий. Объясню на примере.
Архитектор редко создаёт с нуля. Чаще всего мы попадаем в legacy-контекст: часть системы уже живёт, и её нельзя просто выкинуть. Или приходят новые ограничения: «Сейчас у нас 100 заказов в день, через год ожидаем 10 000».
Выяснение текущего состояния системы и планов по её дальнейшему развитию — то, о чём большинство кандидатов забывает, как только у них начинает вырисовываться в голове примерный черновик архитектуры.
На доске эта ось выглядит как пометки по углам: AS IS (Legacy, текущее) и TO BE (Target, целевое). В одном углу схемы у нас старый монолит, в другом — новые микросервисы, и они должны как-то взаимодействовать в переходный период.
Суть в том, что Крест позволяет нарисовать монолит слева сверху, а целевой микросервис — справа, и соединить их пунктиром миграции (например, паттерн «удушающая лоза»). Это демонстрирует зрелость: кандидат не просто фантазирует об идеальном мире, а умеет вписывать новое в существующие ограничения. Ты показываешь, что понимаешь разницу между проектированием в условиях greenfield и brownfield.
На собеседовании эта ось проявляется в таких фразах:
«Каталог блюд сейчас в монолитной 1С, но в целевой архитектуре мы выносим его в отдельный сервис».
«Очереди пока нет, будем писать в БД. Когда вырастем до 100 транзакций в секунду — поставим Kafka».
«Сейчас отчёты загружаются вручную раз в месяц, но в TO BE мы перейдём на синхронную интеграцию, когда источник будет готов».
Ось Z — это машина времени. Она показывает, что ты не просто «рисовальщик» архитектуры, а инженер изменений. Ты видишь не только то, какой система должна стать в конце, но и как она такой станет.
Пошаговый набросок
Надеюсь, теоретическую часть я смог донести. Теперь давай попробуем накидать что-нибудь по этому фреймворку в привычном всем draw.io. Олды могут взять лист бумаги с маркером или гелевой ручкой (ими же гораздо приятнее писать, правда)?
Шаг 1. Рисуем оси
Наметим основных участников системы, без детализации. Нарисуем оси X и Y:
Горизонтальная линия — поток данных (основная ось, тракт распространения информации), вертикальная — слои архитектуры (скелет системы).
Примечание: На этом шаге проговариваем что-то вроде «Обозначим верхнеуровневые блоки системы, чуть позже я их декомпозирую».
Шаг 2. Очерчиваем границы
Теперь наполним ось Х подробностями.
Слева — источники. Выписываешь ВСЕ источники данных, которые удалось выяснить. Здесь не экономим. Даже если сомневаешься — пиши. Потом отфильтруем лишнее.
Задаём интервьюеру уточняющие вопросы:
«Кто инициирует процесс? Это внешний пользователь, внутренний сотрудник, смежная система, файловый обменник?»
«Есть ли автоматические источники (API, Cron, CDC, IoT)?»
«Откуда приходят данные для обработки?»
Пример: «Клиент (мобильное приложение), ресторан (планшет), администратор (веб-консоль), внешняя система доставки (Kafka)».
Справа — потребители. Выписываешь ВСЕ выходы, всех потребителей результата:
«Кто увидит итог? Пользователь на экране, менеджер в BI-отчёте, смежник в своей системе?»
«Какие системы получают результат (DWH, API партнёра, SMS-шлюз)?»
Примечание: здесь говорим что-то наподобие «Я фиксирую возможные источники слева и потребителей справа. Я ничего не упустил, есть что-то ещё?"
Шаг 3. Проводим ток
Воспроизводим сквозной сценарий и соединяем источник с потребителем через центр, где будет располагаться ядро бизнес-логики.
Красной или жирной линией рисуем главный Critical Path. Это тракт данных, соответствующий пути пользователя до успешного достижения им своей цели в системе.
Пример: «Клиент (слева) → мобильное приложение (Front) → API-шлюз (Back) → база заказов (Data) → вызов API службы доставки (справа)».
Обычными линиями отображаем фоновые и второстепенные цепочки:
отправка логов в Elasticsearch;
синхронизация с DWH для аналитики;
инвалидация кеша при обновлении цен;
уведомление в Telegram администраторам.
Примечание: можно не рисовать линию, а просто водить курсором мышки с комментариями вроде «Вот так проходит путь данных от самого входа до конечного потребителя. Это критический путь системы. Отобразил также фоновые процессы — они важны, но не критичны для первого релиза».
Это ключевой шаг. Именно он демонстрирует сквозное мышление. Комментируй вслух, что ты делаешь. Интервьюер должен ловить смысл: не «я рисую стрелки», а «я строю работающий процесс доставки ценности».
Шаг 4. Время делить на части!
Теперь можно углубиться в подробности и разделить слои архитектуры на разные модули. Не нужно пытаться учесть всё возможное, 3-5 модулей на каждом уровне будет вполне достаточно.
Не обязательно соблюдать здесь какую-то нотацию, если вас об этом не просят. Указывайте стрелками направление данных (источник — потребитель), этого будет достаточно в большинстве случаев.
Примечание: здесь отличный момент, чтобы уточнять или задавать самому нефункциональные требования к модулям (см. ниже п. 4.2 про NRF).
Шаг 5. Накладываем изменения
Настало время показать миграцию модулей. Обводишь или помечаешь цветом на схеме участки, где сейчас Legacy (старая БД, монолитный сервис) и где будет Target (новый микросервис, обновлённая архитектура). Рисуешь миграционный пунктир между ними.
Примечание: «Сейчас данные для отчёта отправляются ночным батчем (Legacy), но в целевой архитектуре мы переезжаем на событийный стриминг через Kafka (Target). На схеме это выглядит как выводимые из эксплуатации интеграции (красным) к новым потокам (синий пунктир)».
Теперь твоя схема готова. Пусть не нарисована архитектура во всех подробностях, зато мы продемонстрировали системное мышление.
Стратегия поведения на интервью
Нарисованная схема — это половина успеха на интервью, но также важно уметь красиво и уверенно продать свою идею. «Архитектурный крест» — это инструмент не только проектирования, но и коммуникации. Поэтому отдельно расскажу про тактику поведения на интервью.
Управление вниманием через ось Z
Проектировать молча — ошибка. Интервью — это диалог, а не монолог. Обязательно комментируй, особенно выделяя ось времени. Ты не просто рисуешь, ты вслух демонстрируешь свою инженерную зрелость и опыт работы с реальными ограничениями.
Что говорить:
«Это legacy-модуль. Мы не можем его быстро менять — на него уже завязаны свои процессы. Поэтому сейчас — адаптер-фасад, а потом постепенный переход.»
«Здесь я вижу потенциальное узкое место. В целевой архитектуре мы это решим через кеширование.»
«Сейчас это работает батчем, но через 6 месяцев, когда вырастем до 1000 транзакций в секунду, это будет критично. Поэтому в Target — Kafka.»
Ось Z — это главное место, где ты можешь выделиться и подчеркнуть важность понимания не только технологий, но и способов их постепенной миграции.
Работа с NFR (нефункциональными требованиями)
Декомпозиция оси Y (шаг 4 выше) — отличный момент для уточнений нефункциональных ограничений:
На уровне Data: «Надёжность 99,9%, шардирование по региону, репликация, back-up каждые 4 часа».
На уровне API: «Rate Limiting 100 запросов в секунду на endpoint, авторизация OAuth2, аудит-логи всех запросов».
На уровне Front: «Деградация при отключении API (показываем кешированный список), PWA для оффлайн-режима».
На уровне Business Logic: «Идемпотентные ключи для повторных запросов, SAGA для отмены заказа».
Это не только показывает, что ты умеешь квадратики рисовать, но и демонстрирует твой кругозор и профессиональные навыки.
Использование вопросов интервьюера
Крест во многом провокационная схема. Своей структурой она подталкивает интервьюера задавать ожидаемые вопросы.
Например:
Ты нарисовал «Legacy БД» и «Новая БД» — интервьюер спросит: «Какой формат данных на стыке адаптера и нового сервиса?»
Ты нарисовал «Kafka для стриминга сообщений» — интервьюер спросит: «Как решите проблему повторной доставки при перезапуске потребителя?»
Ты нарисовал «PostgreSQL для заказов» — интервьюер спросит: «Как вы будете шардировать при росте нагрузки?»
Ты сам создаёшь поле для вопросов, к которым можно подготовиться. При определённом навыке прохождения интервью можно вообще взять весь разговор в свои руки:
Нарисовал модуль → упомянул ограничения → ждёшь вопрос.
Если вопроса нет — задай его сам себе: «Возможно, вы спросите, как мы решим проблему X — вот так…»
Ответь, не усложняя: 2-3 предложения и покажи на схеме.
Не жди вопросов, чтобы показать себя. Сам задавай их себе, сам отвечай на них сразу, подавая в виде «я уже подумал об этом, вот как...».
Тайминг
Набросок Креста — первые 5-10 минут задания на интервью. Это время формирования первого впечатления, важно не упустить его на собеседовании. Последующие 10-15 минут — время для углубления и демонстрации своих технических знаний. У тебя уже есть своя песочница, на которой ты можешь их продемонстрировать. Далее ты можешь говорить про более глубокие темы (например, про шардирование, CQRS, Event Sourcing), потому что интервьюер уже будет видеть контекст.
Первое правило: задавай как можно больше уточняющих вопросов. Мало кто въедливо спрашивает условия задачи и ограничения системы.
Второе правило: Не молчи. Говори. Объясняй. Показывай, что ты думаешь. На собеседовании ценится не знание, а процесс мышления. И «Архитектурный крест» — это инструмент не для рисования, а для рассуждения вслух.
Надеюсь, он тебе поможет пройти будущие собеседования и получить крутые офферы. Удачи!