BA & SA | 10000 Interview questions

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

Проблема

В фотохостинге соотношение чтения и записи огромное (например, 1000 просмотров на один пост). Если при каждом просмотре ленты делать сложный запрос к базе (получить посты друзей с пагинацией), база ляжет под нагрузкой даже при скромном количестве пользователей.

Решение — fan-out на запись
Когда пользователь создаёт пост, система не ждёт, пока друзья его увидят. Она заранее (асинхронно) раскладывает ID поста в ленту каждого друга. Лента каждого пользователя — это просто список ID постов (например, в Redis или другой кэш-структуре), отсортированный по времени. При чтении лента отдаётся мгновенно, без обращения к основной базе. Это называется push-модель (fan-out на запись).

Альтернатива (плохая для нагрузки)

Read fan-out (pull) — при каждом запросе ленты искать посты всех друзей. Это убивает производительность.
Почему другие варианты не подходят

A — всё равно каждый запрос нагрузки базу.
C — репликация не решает логику сбора ленты.
D — выбор хранилища не решает проблему: нужна стратегия подготовки ленты.

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

Twitter раньше использовал pull-модель и испытывал проблемы. Перешёл на push для активных пользователей и гибридный подход. Instagram и Facebook генерируют ленту заранее.

Что должен зафиксировать аналитик

«При создании поста его идентификатор должен быть доставлен в ленты всех подписчиков через очередь».
«Лента пользователя хранится в быстром кэше (Redis) в виде отсортированного списка».

№4806 категория вопросов: #SYSTEMDESIGN

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

Когда потребитель не может обработать сообщение (ошибка в данных), бесконечные ретраи бесполезны. Политика должна быть: после N неудачных попыток (например, 3) переместить сообщение в отдельную очередь Dead Letter Queue (DLQ). Основная очередь продолжает чистую работу, а проблемные сообщения копятся в DLQ для ручного анализа и исправления. Без DLQ одно «плохое» сообщение может заблокировать всю очередь. Аналитик обязан требовать настройку DLQ для всех критичных потребителей и указывать количество попыток, интервалы повторных попыток (обычно экспоненциальные 1, 2, 4, 8 секунд) и процедуру обработки DLQ. Это промышленный стандарт для отказоустойчивых систем.

№4805 категория вопросов: #BROKER

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

Когда в запросе WHERE inn = 123 (число) сравнивается с полем VARCHAR, база данных неявно преобразует число в строку для каждой строки таблицы или, что чаще, делает преобразование строки в число для каждой строки индекса. Это делает индекс бесполезным (full scan). Правильное решение — либо передавать строковое значение в кавычках, либо изменить тип поля на числовой. Аналитик должен в требованиях указать, что индексируемые поля, используемые в поиске, должны иметь тип, совместимый с запросами. Реальный случай: оптимизатор PostgreSQL не использует индекс при неявном преобразовании, что приводит к падению производительности на больших таблицах.

№4805 категория вопросов: #DBMS

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

Баги часто возникают на пересечении двух независимых условий: биометрия + смена языка. Тестировщики проверяли биометрию на русском языке и смену языка отдельно, но не комбинацию. Техника парного тестирования или таблиц принятия решений помогает выявить такие сценарии. Аналитик при планировании должен был указать: «для критичных функций (логин, платеж) протестировать все комбинации факторов (язык, тип устройства, способ входа)». В реальном проекте из-за пропуска такой комбинации можно обнаружить баг только в проде, когда пользователи начинают жаловаться.

№4804 категория вопросов: #TESTING

В начале мая сразу несколько новостей показали, куда двигается рынок: спрос на готовые ИТ-бизнесы вырос на 30%, а компании всё активнее пересобирают процессы вокруг ИИ и инфраструктуры. Плюс бизнесу снова приходится быстро адаптироваться к новым правилам и ограничениям — без хороших ориентиров это уже не про рост, а про выживание.

Чтобы не тратить время на случайные каналы и шум, собрали папку с экспертами по IT и бизнесу. Внутри — люди, которые разбирают рынок по делу: без лишней теории, с практикой, кейсами и нормальной аналитикой.

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

Сохранить папку себе 📨

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

«Автоматически» не означает «магически». Система не может сама догадаться, какой товар облагается какой ставкой. Аналитик обязан был задать вопросы: «Откуда системе знать ставку? По каким правилам выбирать 20% или 10%? Есть ли список товаров с исключениями?». Затем разбить на чёткие правила:

Если товар в категории «Продовольствие», то НДС 10%.
Если страна назначения не РФ, то НДС 0%.
Для остальных — 20%.
Без такой детализации разработчик принимает решение по умолчанию, которое почти наверняка окажется неверным. Это реальная проблема на проектах, где бизнес-правила сложны. Аналитик должен превращать «автоматически» в алгоритм.

№4803 категория вопросов: #REQUIREMENTS

Science & Education 🌍🔬

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

Мы отобрали каналы, которые реально помогают в обучении и работе: от свежих научных публикаций и EdTech-трендов, советов по управлению сложными интеллектуальными проектами до актуальных подборок стипендий и грантов по поступлению в топовые вузы мира🔥

👉 ОТКРЫТЬ ДОСТУП

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

1. Суть задачи

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

2. Как работает AND-шлюз

Fork (разветвление): шлюз с одним входом и двумя выходами. Поток разделяется на две параллельные ветки. Обе выполняются одновременно.
Join (слияние): шлюз с двумя входами и одним выходом. Он пропускает поток дальше только после того, как все входящие ветки завершились.
Соединяя fork и join, вы получаете параллельное выполнение с синхронизацией.

3. Почему не подходят другие шлюзы

XOR (исключающий) — активирует только один путь из нескольких. Если поставить XOR, будет выполнена только одна проверка, вторая не запустится. Не подходит.
OR (включающий) — может активировать один или несколько путей. Но при слиянии OR продолжает работу после завершения первой активированной ветки, не дожидаясь остальных. Это не гарантирует выполнения обеих проверок.
Событийный шлюз — выбирает путь на основе наступления события (таймер, сообщение). Для параллельного выполнения не используется.

4. Реальный кейс

В банке процесс выдачи кредита изначально был последовательным: сначала скоринг (1 минута), потом кредитная история (1 минута). Заявка обрабатывалась 2 минуты. Аналитик перерисовал процесс с AND-шлюзом: проверки запускаются параллельно, общее время сократилось до 1 минуты. Клиенты стали получать решение в два раза быстрее.

5. Дополнительные детали для аналитика

Дорожки (swimlanes) помогают показать, кто за какую проверку отвечает (скоринг — отдел рисков, кредитная история — бюро).
Таймеры можно прикрепить к каждой ветке: если одна проверка зависла, через 30 секунд отправить уведомление администратору.
Исключения: если одна из проверок падает с ошибкой, то join не сработает. Нужно добавить шлюз для обработки ошибок (например, если скоринг недоступен, вернуть отказ).

Вывод: AND-шлюз (fork/join) — ключевой элемент BPMN для параллельного выполнения независимых задач и синхронизации. Его правильное применение сокращает время процессов и повышает эффективность.

№4802 категория вопросов: #BPMN