☀Объяснение:

Проблема

Если в БД хранить время без зоны (timestamp), то каждый клиент интерпретирует его по своему часовому поясу (или вообще неверно). Решение: хранить все времена в UTC (единая глобальная шкала). При показе: брать временную зону пользователя (из профиля, геолокации) и преобразовывать.

Почему B оптимально

Универсальность: данные внутри системы всегда согласованы.
Миграция: если текущие записи трактовались как местное время (например, московское), нужно точно знать, в какой зоне они были сохранены, и преобразовать их в UTC (обратимая операция).
Альтернативы

A – преобразовать в timestamptz, но это полумера.
C – избыточно, сложно.
D – неприемлемо для международных систем.

Реальный пример

Booking.com хранит даты заезда в UTC, а показывает в локали пользователя.
Требования
Все временные метки в БД – TIMESTAMP WITH TIME ZONE или timestamp в UTC.
Конвертация происходит на уровне представления.

☀Объяснение:

Что демонстрирует кандидат
Понимание, что оценка без контекста — гадание.
Умение задавать уточняющие вопросы:
Какой провайдер (Google, собственный)?
Есть ли готовый SDK, примеры?
Требуется ли поддержка мобильных приложений?
Как обновлять токены, как хранить секреты?
Выделение рисков: если документация плохая или провайдер меняет API, то срок может вырасти вдвое.

Почему правильный ответ B
Интервьюеры хотят видеть аналитический склад ума, а не цифру.

Реальный опыт
Кандидат, который задавал вопросы, получил оффер, а тот, кто назвал 3 дня без уточнений — нет.

Вывод
На собеседовании никогда не давайте оценки без уточнения контекста.

80% системных аналитиков заваливают собеседования из-за глупых ошибок

Самый простой способ подготовиться к собеседованию — это послушать, как его проходят другие.

В канале System | Собеседования собрали базу реальных технических интервью, чтобы вы могли учиться на чужих ошибках, а не на своих.

Что внутри:
💘 Разборы живых записей — от проектирования API до работы с БД
💘 Ключевые вопросы лидов из бигтеха
💘 Анализ ответов — где кандидат «поплыл» и как нужно было ответить правильно

Подписывайтесь, чтобы получить доступ к базе живых разборов и увереннее чувствовать себя на собесах.

☀Объяснение:

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

Что такое XOR-шлюз
Исключающий шлюз (XOR) имеет один вход и несколько выходов (или наоборот, несколько входов и один выход при слиянии). При ветвлении он активирует ровно один путь, проверяя условия-охранники (например, [сумма > 1 млн] и [сумма <= 1 млн]). При слиянии он пропускает поток дальше, когда завершится любой из входящих путей (но в данном случае слияние не требуется).

Как моделировать
Шаг 1: после создания заявки — XOR-шлюз с двумя исходящими потоками:
Условие 1: сумма > 1 млн → задача «Подпись финдиректора».
Условие 2: сумма ≤ 1 млн → задача «Подпись руководителя отдела».
Затем оба потока сходятся в общую точку (например, в задачу «Передать в бухгалтерию»).

Почему не другие шлюзы
AND — запустил бы оба пути одновременно (подпись и финдиректора, и руководителя) и потребовал бы завершения обоих, что неверно.
OR — мог бы активировать один или оба пути, тоже не подходит.
Событие-таймер — ждёт наступления времени, не имеет отношения к условиям.

Реальный пример
В ERP-системе закупки до определённой суммы утверждает начальник отдела, выше — финансовый контролёр. XOR-шлюз идеально отображает это правило.

Вывод
XOR применяется для ветвления «или-или» на основе бизнес-данных. Аналитик должен правильно выбрать тип шлюза в зависимости от логики.

☀Объяснение:

Проблема
Наивное описание синхронными сообщениями (сплошная стрелка с заполненным концом) подразумевает, что вызывающий объект ждёт ответа. Для внешнего платёжного шлюза типично: вы отправляете запрос, затем получаете асинхронный ответ через некоторое время (callback, webhook). Изображать это как синхронный вызов неправильно.
Как правильно

Асинхронное сообщение — открытая стрелка (линия со стрелкой на конце, но без заливки). Оно означает, что управление не блокируется.
Получение callback — изображается как входящее асинхронное сообщение от банка к контроллеру, часто с пометкой «callback» или «webhook».
Можно также использовать фрагмент async или показать запуск отдельного потока (активационная полоска).

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

Реальный пример
В интеграции с PayPal: ваш сервер отправляет запрос и продолжает работу. Через несколько секунд PayPal присылает уведомление на ваш endpoint. На диаграмме последовательности это показывается как два асинхронных сообщения (туда и обратно), возможно, с фреймом par для параллельных действий.

Вывод
Аналитик, рисуя диаграмму последовательности, должен различать синхронные и асинхронные вызовы. Это влияет на проектирование таймаутов, ретраев и обработки callback.

☀Объяснение:

Требования
Врач (роль) — доступ к картам пациентов, но только своего отделения (контекст — отделение).
Администратор — все карты (вышестоящая роль).
Лаборант — доступ только к типу данных «анализы» (контекст — тип данных).

Почему RBAC с контекстными ограничениями
Ролевая модель (RBAC) назначает разрешения ролям, а не пользователям. Врачи, лаборанты, админы — это роли. Добавляются ограничения:
У врача: условие patient.department == user.department.
У лаборанта: условие data_type == 'lab_results'.
У администратора: нет условий.

Почему не другие
DAC — владелец данных решает, кому дать доступ. Не подходит для медорганизации.
MAC — жёсткая классификация (секретно/несекретно), не подходит для бизнес-правил.
Только ACL — глобальные списки доступа для каждого объекта, трудоёмко.

Реальный пример
Electronic Health Record (EHR) системы используют RBAC с атрибутами (отделение, специализация). Лаборанты видят анализы, но не диагнозы (диагнозы только у врачей).

Что должен зафиксировать аналитик
Роли и права.
Контекстные ограничения (фильтры).
Иерархию ролей (старшая роль включает младшие).

☀Объяснение:

Проблема
Нереалистичные нефункциональные требования (NFR) — частая ошибка стартапов. Заказчик может назвать цифру «10 000» без обоснования, потому что «конкуренты так могут» или «на всякий случай».

Что должен сделать аналитик
Уточнить источник цифры: откуда ожидается такой рост, есть ли маркетинговые прогнозы или это просто желание.
Предложить компромисс: сделать архитектуру, которая позволит горизонтально масштабироваться, но не строить инфраструктуру на полную мощность сейчас (например, использовать облачные сервисы с автосейлингом).
Задокументировать риск: «При резком росте нагрузки без дополнительных инвестиций система может не выдержать. Требуется повторная оценка через 6 месяцев».

Почему не другие варианты
A — согласиться без анализа — приведёт к перерасходу бюджета или невыполнимому обязательству.
C — отказ от проекта без попытки обсуждения — не гибко.
D — игнорирование — безответственно.

Реальный кейс
Один стартап по доставке еды требовал 5000 RPS с первого дня. Аналитик предложил использовать масштабируемый облачный кластер, но с минимальной конфигурацией. После запуска пик оказался 50 RPS. Экономия составила 80% бюджета.