BA & SA | 10000 Interview questions
10.4K subscribers
191 photos
14 videos
364 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
Объяснение:

Проблема:
HTTP POST не является идемпотентным по определению. Если клиент повторяет запрос из-за таймаута, сервер не может отличить повтор от нового запроса. Это приводит к дублированию операций (списаний, созданий заказов).

Решение – идемпотентный ключ (Idempotency Key):
Клиент генерирует уникальный ключ (например, UUID) и передаёт его в заголовке 
Idempotency-Key. Сервер хранит этот ключ вместе с результатом операции в течение определённого времени (например, 24 часа). При повторном запросе с тем же ключом сервер возвращает ранее сохранённый результат, не выполняя операцию повторно.

Алгоритм работы сервера:
Получить ключ из заголовка.
Проверить в хранилище (Redis, БД), есть ли уже выполненная операция с этим ключом.
Если есть – вернуть сохранённый ответ.
Если нет – выполнить операцию (списание денег), сохранить ключ и результат, затем вернуть ответ.
Пример кода (Node.js):
javascript
const idempotencyKey = req.headers['idempotency-key'];
const cached = await redis.get(idempotencyKey);
if (cached) return JSON.parse(cached);
const result = await processPayment(req.body);
await redis.setex(idempotencyKey, 86400, JSON.stringify(result));
res.json(result);

Почему не подходят другие варианты:
B (IP-адрес) – не надёжен: несколько клиентов за NAT, динамические IP.
C (rate limiting) – не решает дублирование из-за таймаута, а лишь ограничивает частоту.
D (DELETE) – не подходит для создания ресурса/списания средств.

Реальный пример:
Stripe требует обязательный заголовок 
Idempotency-Key для идемпотентных запросов. Это позволяет клиентам безопасно повторять запросы при сетевых сбоях.

Что должен зафиксировать аналитик:
«API должен поддерживать заголовок Idempotency-Key для всех небезопасных методов (POST, PUT, PATCH)».
«Ключ должен храниться не менее 24 часов».
«Ответ на повторный запрос с тем же ключом должен быть идентичен первому».

Вывод: Idempotency Key – стандарт защиты от двойной обработки в REST API, обязательный для финансовых и критических операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
IT & Digital
Папка для тех, кто погружен в мир разработки, программирования, данных, ИИ, цифрового маркетинга, аналитики, UX/UI дизайна, управления IT-проектами и развития tech-продуктов.

👉 Сохранить себе
№4890 категория вопросов: #UML
4890. В системе 10 микросервисов. Нужно показать, как запрос на оформление заказа проходит через них, с указанием порядка вызовов (1, 2, 3…). Какая диаграмма UML лучше подходит, когда важны не временные отрезки, а структура взаимодействия?
Anonymous Quiz
66%
Диаграмма последовательности (Sequence)
29%
Диаграмма коммуникации (Communication)
2%
Диаграмма классов
3%
Диаграмма деятельности
Объяснение:

Диаграмма коммуникации (раньше называлась диаграммой кооперации) фокусируется на связях между объектами/компонентами и нумерует сообщения в порядке их передачи. В отличие от диаграммы последовательности, где время течёт вертикально, здесь время показано номерами (1, 1.1, 2 и т.д.), а пространственное расположение отражает топологию связей.

Когда что использовать:
Диаграмма последовательности – лучше для детального анализа временнóй логики, асинхронных вызовов, параллельных процессов. Но при 10 сервисах она становится громоздкой (много линий времени).
Диаграмма коммуникации – компактнее для большого числа участников, хорошо показывает, кто с кем связан, и позволяет быстро пронумеровать вызовы. Отлично подходит для архитектурных обсуждений на доске.

Почему B правильный ответ:
В задаче важны не временные отрезки (сколько миллисекунд), а порядок вызовов и структура связей. Диаграмма коммуникации помещает все микросервисы на один лист и стрелками с номерами показывает последовательность. Это удобно для презентации архитектуры команде и стейкхолдерам.

Реальный пример:
В интеграционном проекте с 6 внешними сервисами диаграмма коммуникации помогла выявить циклические зависимости (А → Б → В → А), которые не замечали на диаграмме последовательности.

Что должен зафиксировать аналитик:
Для описания высокоуровневого потока с большим числом участников использовать диаграмму коммуникации.
Для детальной отладки с таймингами – диаграмму последовательности.

Вывод: Диаграмма коммуникации незаменима, когда нужно показать упорядоченные взаимодействия между многими участниками, не загромождая временными полосками.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4891 категория вопросов: #ARCHITECTURE
4891. Команда выпускает новую версию микросервиса, но при обновлении возникает простой 2 минуты, пока старые поды заменяются новыми. Какой стратегией деплоя можно полностью исключить простой и мгновенно переключать трафик между средами?
Anonymous Quiz
32%
Rolling update
47%
Blue‑Green deployment
20%
Canary deployment
1%
A/B тестирование
Объяснение:

Blue‑Green deployment – это техника, при которой существуют два идентичных окружения: «синее» (blue, текущая production-версия) и «зелёное» (green, новая версия).
Новая версия разворачивается в зелёной среде, пока синяя продолжает обслуживать трафик.
Проводятся smoke-тесты зелёной среды.
В один момент (атомарно) переключается маршрутизатор (балансировщик, DNS), и весь трафик направляется на зелёную среду.
Если возникли проблемы – переключаем обратно на синюю за секунды.
Синяя среда сохраняется как резервная, позже удаляется.
Почему отсутствует простой:
Переключение трафика происходит мгновенно (обновление конфигурации балансировщика или смена DNS-записи). Старые поды не удаляются до переключения, поэтому пользователи не замечают никакого прерывания.

Сравнение с другими стратегиями:
Rolling update (A) – постепенная замена подов. Может быть почти незаметным, но требует, чтобы приложение было отказоустойчивым к разным версиям одновременно. Риск – простой при ошибке в последней партии.
Canary deployment (C) – сначала новая версия получает небольшой процент трафика (например, 1%), что позволяет оценить работу, но для бездымного переключения на 100% также нужен финальный атомарный шаг.
A/B тестирование (D) – не про деплой, а про эксперименты.

Реальный пример:
В Netflix используется Blue‑Green для критических сервисов. Перед переключением проводят полный цикл интеграционного тестирования в зелёной среде. При обнаружении проблем – просто не переключают трафик.

Что должен зафиксировать аналитик:
Требование: «Критические сервисы должны разворачиваться по стратегии Blue‑Green с нулевым временем простоя».
Наличие двух полных окружений (ресурсы могут быть уменьшены на время, но должны быть готовы к переключению).
Процедура отката – переключение обратно на blue.

Вывод: Blue‑Green deployment – золотой стандарт для систем, где недопустим простой, но требует удвоения ресурсов во время деплоя.
Please open Telegram to view this post
VIEW IN TELEGRAM
Нейросети, IT и AI — в одной папке

💬 С коллегами собрали новые каналы про:

💠 промпты для нейросетей и готовые решения
💠 AI-фотосессии, генерация изображений и контента
💠 новости искусственного интеллекта без лишнего шума
💠 применение AI в работе, бизнесе и повседневной жизни
💠 Python, JavaScript, Data Science и системный анализ
💠 вакансии и возможности для специалистов в IT


Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi

💌 Добавить свой канал в папку
№4892 категория вопросов: #INTEGRATION
4892. API возвращает поле customer_name. В новой версии поле переименовали в full_name. Чтобы не ломать старых клиентов, сервер должен поддерживать обе версии одновременно. Как клиент может указать, какую версию API он хочет получить?
Anonymous Quiz
12%
Добавить параметр ?version=2 в URL
23%
Указать версию в заголовке Accept: application/vnd.myapi.v2+json
61%
Использовать разные endpoint-ы /v1/customers и /v2/customers
4%
Передать версию в теле запроса
Объяснение:

При эволюции API часто приходится менять названия полей, типы или удалять устаревшие атрибуты. Прямое изменение сломает всех существующих клиентов. Необходимо поддерживать несколько версий одновременно, позволяя клиенту выбирать версию.

Способы версионирования:
Через URL (
/v1/customers/v2/customers) – самый простой и наглядный. Минус: меняется endpoint, клиентам нужно обновлять код вызовов.
Через параметр запроса (
?version=2) – менее явно, может кэшироваться некорректно.
Через заголовок Accept – стандартный способ для REST, основанный на медиатипах. Клиент указывает желаемую версию в заголовке, например: 
Accept: application/vnd.myapi.v2+json. Сервер, прочитав заголовок, сериализует ответ в соответствующем формате.

Почему B – правильный ответ:
Использование 
Accept соответствует принципам REST (content negotiation).
Не засоряет URL, сохраняет единый endpoint.
Позволяет гибко комбинировать версию и формат (JSON, XML).

Сравнение с другими вариантами:
A (параметр 
?version) – тоже возможен, но менее чистый с точки зрения REST.
C (разные URL) – классический подход, но вопрос явно описывает заголовок как способ указать версию.
D (тело запроса) – нестандартно, требует разбора тела до того, как будет понята версия (курица-яйцо).

Реальный пример:
GitHub API версионирует через заголовок 
Accept: application/vnd.github.v3+json. Это позволяет им добавлять новые поля, не ломая старых клиентов.

Что должен зафиксировать аналитик:
В требованиях указать, что API поддерживает версионирование через заголовок 
Accept.
Документировать возможные значения (v1, v2, latest).
Определить политику депрекации старых версий.

Вывод: Версионирование через заголовок 
Accept – гибкий и REST-совместимый способ, особенно когда URL должен оставаться стабильным.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4893 категория вопросов: #DBMS
4893. В таблице counters есть поле value. Два параллельных запроса могут прочитать одно и то же значение, увеличить и записать, что приведёт к потере одного инкремента. Какая SQL-конструкция гарантирует атомарное увеличение без блокировок на чтение?
Anonymous Quiz
14%
SELECT value FROM counters WHERE id = 1; UPDATE counters SET value = value + 1 WHERE id = 1;
35%
UPDATE counters SET value = value + 1 WHERE id = 1 (один запрос)
37%
BEGIN; SELECT ... FOR UPDATE; UPDATE ...; COMMIT;
15%
INSERT INTO counters (value) VALUES (1) ON DUPLICATE KEY UPDATE value = value + 1
Объяснение:

Проблема – состояние гонки (race condition):
Два процесса одновременно читают 
value = 5, увеличивают в памяти до 6, затем оба записывают 6. В результате значение станет 6, хотя должно было стать 7 (потерян один инкремент).

Решение – атомарный UPDATE:
В большинстве реляционных СУБД (PostgreSQL, MySQL, Oracle) оператор 
UPDATE SET value = value + 1 является атомарным. База данных блокирует строку на время обновления, но не блокирует чтение (за счёт MVCC в PostgreSQL или разных механизмов). При параллельных вызовах второй вызов увидит уже увеличенное значение и корректно увеличит его ещё раз.

Почему не подходят другие варианты:
A (два отдельных запроса) – не атомарно, гонка неизбежна.
C (
SELECT ... FOR UPDATE) – да, решает проблему, но блокирует строку даже для чтения другими транзакциями (пессимистическая блокировка). Это может снизить производительность. Атомарный UPDATE обычно быстрее.
D (UPSERT) – работает, но тяжеловесно, если гарантированно существует запись.

Важно для аналитика:
Если нужен атомарный инкремент – используйте один UPDATE.
Если нужно прочитать старое значение перед обновлением (например, для логирования), то придётся использовать 
SELECT ... FOR UPDATE в транзакции.
Для высоконагруженных счётчиков (лайки, просмотры) часто используют Redis (атомарный 
INCR), а периодически синхронизируют с БД.

Реальный пример:
В счетчике просмотров видео на YouTube используется атомарный UPDATE в базе данных для финальной консистентности, а промежуточные инкременты накапливаются в Redis.

Что должен зафиксировать аналитик:
«При обновлении счётчика использовать атомарный 
UPDATE SET field = field + 1 без предварительного чтения».
Если нужно получить предыдущее значение – оформить требование на пессимистическую блокировку.

Вывод: Простой атомарный UPDATE – самое производительное и надёжное решение для счётчиков без необходимости читать старое значение.
Please open Telegram to view this post
VIEW IN TELEGRAM
2
⁉️ Устал искать интересные каналы с ИИ новостями?

📁 ДОБАВИТЬ ВСЕ КАНАЛЫ

В этой папке собраны каналы про ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.

😏 ЗАБРАТЬ ПАПКУ МОЖНО ТУТ

Папка действует 72 часа.

🤩 Организаторы: Green.Papka
Please open Telegram to view this post
VIEW IN TELEGRAM
№4894 категория вопросов: #ARCHITECTURE
4894. Команда хочет выкатить новую версию рекомендательного сервиса, но не уверена в её стабильности. Нужно сначала направить на неё 1% трафика, а если ошибок нет – постепенно увеличивать. Какая стратегия деплоя это позволяет?
Anonymous Quiz
16%
Rolling update
48%
Canary deployment
27%
Blue‑Green deployment
10%
Shadow deployment
Объяснение:

Что такое Canary deployment?
Название происходит от практики «канарейки в угольной шахте» (раньше шахтёры брали с собой канарейку – если она падала, значит, есть угарный газ). В IT – это стратегия, при которой новая версия приложения сначала получает маленькую долю трафика (например, 1% пользователей или запросов). Затем команда наблюдает за метриками (ошибки, время отклика). Если всё хорошо, доля постепенно увеличивается (5%, 20%, 50%, 100%). Если возникают проблемы, можно быстро откатить, направив 100% трафика на старую версию.

Чем отличается от других стратегий:
A (Rolling update) – постепенная замена подов, но трафик распределяется между старыми и новыми подами, а не контролируется на уровне процентного соотношения.
C (Blue‑Green) – требует двух полных окружений и мгновенного переключения. Не позволяет постепенно наращивать трафик.
D (Shadow deployment) – новая версия получает «теневой» трафик (копию запросов), но не обслуживает реальных пользователей. Хорошо для тестирования под нагрузкой, но не для проверки на реальных пользователях.

Реальный пример:
Netflix, Google, Amazon используют canary deployment для критических сервисов. Например, новая версия поиска сначала обрабатывает 0.5% запросов, а затем, если метрики в норме, долю увеличивают.

Что должен зафиксировать аналитик:
Требование: «Выкатка новых версий должна происходить по стратегии канареечного релиза с возможностью контролировать процент трафика».
Определить ключевые метрики для автоматического отката (например, увеличение ошибок 500 более чем на 0.1%).

Вывод: Canary deployment – идеальный выбор, когда нужно снизить риски, выпуская новую функциональность постепенно.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
№4895 категория вопросов: #DBMS
4895. В CRM нужно реализовать «корзину»: удалённые заказы должны восстанавливаться в течение 30 дней, после чего удаляться навсегда. Как спроектировать хранение удалённых заказов без падения производительности основных запросов?
Anonymous Quiz
38%
Добавить в таблицу orders поле is_deleted (мягкое удаление) с индексом
47%
Создать отдельную таблицу deleted_orders и фоновым процессом переносить туда записи
3%
Удалять заказы сразу физически и хранить резервные копии
11%
Использовать партиционирование по дате удаления