4819. Вы описали диаграмму последовательности для сценария «Оплата заказа». В ней участвуют объекты: Клиент, Контроллер, СервисПлатежей, Банк. На самом деле Банк — внешняя система, отвечающая асинхронно через callback. Как это правильно изобразить?
Anonymous Quiz
2%
Простым сообщением без изменений
94%
Асинхронным сообщением и отдельным обратным асинхронным сообщением или получением callback
2%
Синхронным сообщением, но с таймаутом
3%
Не изображать взаимодействие с банком, так как это деталь реализации
Наивное описание синхронными сообщениями (сплошная стрелка с заполненным концом) подразумевает, что вызывающий объект ждёт ответа. Для внешнего платёжного шлюза типично: вы отправляете запрос, затем получаете асинхронный ответ через некоторое время (callback, webhook). Изображать это как синхронный вызов неправильно.
Как правильно
Асинхронное сообщение — открытая стрелка (линия со стрелкой на конце, но без заливки). Оно означает, что управление не блокируется.
Получение callback — изображается как входящее асинхронное сообщение от банка к контроллеру, часто с пометкой «callback» или «webhook».
Можно также использовать фрагмент
asyncПочему это важно
Асинхронное взаимодействие даёт другую последовательность: клиент получит подтверждение не сразу, а позже. На диаграмме это влияет на временные рамки.
Реальный пример
В интеграции с PayPal: ваш сервер отправляет запрос и продолжает работу. Через несколько секунд PayPal присылает уведомление на ваш endpoint. На диаграмме последовательности это показывается как два асинхронных сообщения (туда и обратно), возможно, с фреймом
parВывод
Аналитик, рисуя диаграмму последовательности, должен различать синхронные и асинхронные вызовы. Это влияет на проектирование таймаутов, ретраев и обработки callback.
Please open Telegram to view this post
VIEW IN TELEGRAM
4820. Врач в медицинской системе должен иметь доступ к картам пациентов только своего отделения. Администратор больницы — ко всем. Лаборант — только к результатам анализов, но не к диагнозам. Какая модель разграничения доступа наиболее подходит?
Anonymous Quiz
0%
Дискреционная (DAC)
97%
Ролевая (RBAC) с иерархией ролей и контекстными ограничениями (отделение, тип данных)
1%
Мандатная (MAC) с метками «секретно»
2%
Только полномочия по списку (ACL)
Врач (роль) — доступ к картам пациентов, но только своего отделения (контекст — отделение).
Администратор — все карты (вышестоящая роль).
Лаборант — доступ только к типу данных «анализы» (контекст — тип данных).
Почему RBAC с контекстными ограничениями
Ролевая модель (RBAC) назначает разрешения ролям, а не пользователям. Врачи, лаборанты, админы — это роли. Добавляются ограничения:
У врача: условие
patient.department == user.departmentУ лаборанта: условие
data_type == 'lab_results'У администратора: нет условий.
Почему не другие
DAC — владелец данных решает, кому дать доступ. Не подходит для медорганизации.
MAC — жёсткая классификация (секретно/несекретно), не подходит для бизнес-правил.
Только ACL — глобальные списки доступа для каждого объекта, трудоёмко.
Реальный пример
Electronic Health Record (EHR) системы используют RBAC с атрибутами (отделение, специализация). Лаборанты видят анализы, но не диагнозы (диагнозы только у врачей).
Что должен зафиксировать аналитик
Роли и права.
Контекстные ограничения (фильтры).
Иерархию ролей (старшая роль включает младшие).
Please open Telegram to view this post
VIEW IN TELEGRAM
4821. Вы аналитик в стартапе. Заказчик требует, чтобы система обрабатывала 10 000 заказов в секунду, хотя текущий пик — 10 заказов в секунду. Разработка такого уровня масштабирования обойдётся в утроение бюджета. Ваши действия?
Anonymous Quiz
0%
Принять требование и искать более дешёвую реализацию
100%
Анализ: спросить заказчика, откуда взялась цифра, предложить альтернативу и задокументировать риск.
0%
Отказаться от проекта
0%
Добавить требование в бэклог и забыть
Нереалистичные нефункциональные требования (NFR) — частая ошибка стартапов. Заказчик может назвать цифру «10 000» без обоснования, потому что «конкуренты так могут» или «на всякий случай».
Что должен сделать аналитик
Уточнить источник цифры: откуда ожидается такой рост, есть ли маркетинговые прогнозы или это просто желание.
Предложить компромисс: сделать архитектуру, которая позволит горизонтально масштабироваться, но не строить инфраструктуру на полную мощность сейчас (например, использовать облачные сервисы с автосейлингом).
Задокументировать риск: «При резком росте нагрузки без дополнительных инвестиций система может не выдержать. Требуется повторная оценка через 6 месяцев».
Почему не другие варианты
A — согласиться без анализа — приведёт к перерасходу бюджета или невыполнимому обязательству.
C — отказ от проекта без попытки обсуждения — не гибко.
D — игнорирование — безответственно.
Реальный кейс
Один стартап по доставке еды требовал 5000 RPS с первого дня. Аналитик предложил использовать масштабируемый облачный кластер, но с минимальной конфигурацией. После запуска пик оказался 50 RPS. Экономия составила 80% бюджета.
Please open Telegram to view this post
VIEW IN TELEGRAM
4822. Сервис А, получив ошибку, начал повторять запросы каждую секунду, создавая лавину нагрузки на сервис В, которая не давала ему восстановиться. Как называется этот эффект и как его предотвратить?
Anonymous Quiz
13%
Deadlock; использовать распределённую блокировку
84%
Retry storm; использовать экспоненциальную задержку и ограничение числа ретраев,плюс Circuit Breaker
2%
Race condition; добавить идемпотентность
2%
Thundering herd; использовать очереди
Когда сервис В недоступен, множество экземпляров сервиса А одновременно начинают повторные попытки с фиксированным интервалом. Это создаёт синхронизированные всплески нагрузки, которые мешают восстановлению. Это называется retry storm (шторм повторных вызовов).
Решение
Экспоненциальная задержка (exponential backoff) — интервал между ретраями удваивается (1, 2, 4, 8 секунд). Это раздвигает по времени пики нагрузки.
Джиттер (jitter) — случайное небольшое смещение, чтобы разные экземпляры не синхронизировались.
Ограничение числа ретраев (например, 5 попыток).
Circuit Breaker — после определённого числа ошибок быстрый сброс без вызова вообще.
Почему не другие варианты
A — deadlock относится к блокировкам в БД.
C — race condition — состояние гонки, не то.
D — thundering herd — асинхронная проблема, но решение с очередями не прямое.
Реальный случай
В Amazon одна из внутренних систем легла из-за retry storm. После внедрения экспоненциального бэккотта и джиттера инциденты прекратились.
Требования аналитика
Политика ретраев: начальная задержка 1 сек, максимум 10 сек, коэффициент 2, джиттер 0-30%.
Please open Telegram to view this post
VIEW IN TELEGRAM
4823. Нужно отображать бесконечную ленту новостей (скроллинг). Запрос с OFFSET 10000 LIMIT 10работает очень медленно. Какой метод пагинации использовать для большой глубины?
Anonymous Quiz
1%
Повысить размер кэша БД
93%
Пагинация на основе курсора (keyset pagination) — использовать WHERE created_at < последнее_значение
5%
Использовать OFFSET с подзапросом
1%
Сгружать всю таблицу в приложение и фильтровать
Честно, мне кажется, через пару лет навык работы с ИИ будет таким же базовым,
как умение пользоваться интернетом.
И самое интересное — многие это до сих пор недооценивают.
Я для себя собрал папку с сильными экспертами по ИИ.
Там — реальные инструменты, кейсы и способы использовать нейросети с пользой.
Если вам тоже интересна эта тема — добавляйте папку 👇
https://t.me/addlist/KuqHb68lTqhhNDJi
⏳ доступ 48 часов
как умение пользоваться интернетом.
И самое интересное — многие это до сих пор недооценивают.
Кто-то делает всё вручную,
а другие уже экономят часы работы с помощью нейросетей и растут быстрее.
Разница между ними со временем будет только увеличиваться.
Я для себя собрал папку с сильными экспертами по ИИ.
Там — реальные инструменты, кейсы и способы использовать нейросети с пользой.
Если вам тоже интересна эта тема — добавляйте папку 👇
https://t.me/addlist/KuqHb68lTqhhNDJi
⏳ доступ 48 часов
OFFSETПагинация на основе курсора
Вместо
OFFSETSELECT * FROM news WHERE created_at < last_seen_date ORDER BY created_at DESC LIMIT 10Переменная
last_seen_dateПреимущества
База сканирует только нужные строки + ограниченный диапазон.
Работает за O(логарифм) по индексу.
Не зависает на больших смещениях.
Требования
Индекс на поле сортировки (например,
created_atУникальный вторичный ключ для разрешения связей (добавить
idORDER BYРеальный пример
Twitter и Reddit используют курсоры для бесконечной ленты.
Вывод
Аналитик должен потребовать использования курсора вместо
OFFSETPlease open Telegram to view this post
VIEW IN TELEGRAM
4824. В системе из 5 микросервисов при каждом обновлении данных нужно уведомлять 3 других сервиса. Прямые вызовы привели к большой связанности и падению одного сервиса, блокирующему других. Какой архитектурный стиль снизит связанность?
Anonymous Quiz
1%
Перейти на синхронные вызовы с ретраями
99%
Внедрить событийно-ориентированную архитектуру, где сервисы публикуют события в брокер
0%
Сделать всё в одном монолите
0%
Использовать общую базу данных для уведомлений
Прямые синхронные вызовы между сервисами создают жесткую связанность. Когда сервис А вызывает Б, В, Г, то падение любого из них может затронуть А. Событийная архитектура решает это.
Event-driven
Сервис-источник публикует событие в брокер (Kafka, RabbitMQ).
Подписчики (другие сервисы) получают события асинхронно.
Источник не знает о подписчиках и не ждёт ответа.
Отказ одного подписчика не влияет на источник и других.
Почему это снижает связанность
Слабая связанность — публикация события и его обработка разделены.
Отказоустойчивость — брокер буферизует события, упавший подписчик получит их при восстановлении.
Легко добавлять новых подписчиков без изменения источника.
Почему не другие
A — ретраи не решат связанность.
C — монолит против микросервисной идеи.
D — общая БД создаёт другую связанность.
Реальный пример
Upwork перешёл на event-driven и ускорил доставку уведомлений в реальном времени.
Вывод аналитика
Событийная архитектура — стандарт для слабо связанных микросервисов. Аналитик должен в требованиях указывать асинхронное взаимодействие для всех бизнес-событий, не требующих немедленного ответа.
Please open Telegram to view this post
VIEW IN TELEGRAM
4825. Вам нужно оценить стоимость разработки системы для аренды самокатов. Бизнес-функции: «заблокировать самокат», «начать поездку», «завершить поездку», «списать оплату». Какой метод позволит измерить объём требований независимо от технологии?
Anonymous Quiz
10%
Количество пользовательских историй
82%
Метод COSMIC – считаем функциональные процессы, триггеры и объекты данных
1%
Количество экранов в прототипе
7%
Стори-поинты на основе усреднения