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

Решение А: облачная инфраструктура Решение Б: покупка собственных серверов on‑premise (капитальные затраты, фиксированная мощность). Какой метод анализа позволит учесть все расходы
Anonymous Quiz
29%
ROI (Return on Investment)
61%
TCO (Total Cost of Ownership)
6%
NPV (Net Present Value)
4%
Payback period
Объяснение:

Что такое TCO (совокупная стоимость владения)?
TCO – это метод оценки полных затрат на владение и эксплуатацию актива (в данном случае – ИТ-системы) в течение всего жизненного цикла. В отличие от закупочной цены, TCO включает:
Прямые затраты: оборудование (серверы, сетевое оборудование), лицензии на ПО, оплата облачных ресурсов.
Косвенные затраты: электроэнергия, охлаждение, аренда дата-центра, зарплата администраторов, обучение персонала, поддержка, страхование, утилизация оборудования.
Транзакционные затраты: время на миграцию данных, простои при обновлениях, оплата трафика.

Почему для сравнения «облако vs on‑premise» нужен именно TCO?
ROI (A) – показывает прибыль от инвестиций, но требует прогноза доходов, что часто субъективно. ROI не учитывает все эксплуатационные расходы.
NPV (C) – чистая приведённая стоимость, учитывает временную стоимость денег, но требует дисконтирования будущих денежных потоков, что усложняет расчёт и также зависит от прогнозов доходов.
Payback period (D) – срок окупаемости, показывает, когда инвестиции вернутся, но не даёт полной картины затрат на 5 лет.
TCO даёт объективную цифру: «Решение А обойдётся в X миллионов рублей за 5 лет, решение Б – в Y». Это позволяет руководству принимать взвешенное решение без спекуляций.

Реальный пример из практики:
Компания выбирала между AWS и собственным дата-центром. TCO-анализ показал, что on‑premise дешевле при нагрузке > 80% использования серверов, но облако выгоднее при переменной нагрузке (сезонные пики). В итоге выбрали гибридную модель. Без TCO руководство могло бы переплатить миллионы.

Что должен зафиксировать аналитик:
В требованиях к оценке архитектурных альтернатив указать необходимость расчёта TCO на 5 лет.
Включить все категории затрат (не только capex/opex).
Учесть риски (например, рост цен на облачные ресурсы или стоимость утилизации серверов).

Вывод: TCO – обязательный инструмент аналитика при сравнении архитектурных решений, когда речь идёт о многолетних инвестициях. Он даёт объективную основу для переговоров с руководством и финансовым отделом.
Please open Telegram to view this post
VIEW IN TELEGRAM
Сегодня выигрывает не тот, кто больше работает.

Выигрывает тот, кто умеет привлекать клиентов, строить продажи и правильно использовать маркетинг.

Можно годами искать информацию по разным каналам, покупать десятки курсов и совершать одни и те же ошибки.


А можно взять готовую базу знаний, где уже собраны материалы по самым важным направлениям:
• продажи и переговоры
• маркетинг и продвижение
• привлечение клиентов
• создание воронок
• монетизация и масштабирование

Эта папка https://t.me/addlist/LcfUVqDykUllYzUy поможет вам быстрее разобраться в том, что действительно приносит деньги, а что только отнимает время.

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

Полезные знания окупаются быстрее любых вложений https://t.me/addlist/LcfUVqDykUllYzUy

Записывайся в подборку
№4898 категория вопросов: #ARCHITECTURE
4898. В сервисе с Redis и PostgreSQL при обновлении: сначала БД, потом инвалидация кэша. Из-за гонки другой запрос может прочитать старый кэш. Какой паттерн решает проблему без 2PC?
Anonymous Quiz
18%
Обновлять кэш синхронно в той же транзакции, что и БД
69%
Использовать Change Data Capture (CDC) для асинхронного обновления кэша
10%
Блокировать запись в кэш на время обновления БД
3%
Всегда читать данные напрямую из БД
Объяснение:

Проблема (почему Cache‑Aside не всегда безопасен)
В типичной схеме Cache‑Aside вы делаете:
UPDATE в БД.
DELETE ключа в Redis (или обновление).
Между этими операциями (в микросекунды) другой поток может прочитать кэш, в котором лежит старое значение, и вернуть его пользователю, пока БД уже обновлена. Это состояние гонки называется «гонка инвалидации кэша» (cache invalidation race). Она редка, но в высоконагруженных системах случается и приводит к неконсистентным данным. Попытки исправить синхронными блокировками (вариант C) или распределёнными транзакциями (вариант A) убивают производительность и усложняют код.

Почему CDC — лучшее решение
Change Data Capture (CDC) читает журнал транзакций вашей СУБД (WAL в PostgreSQL, binlog в MySQL) и превращает каждое изменение в событие. Это событие содержит старую и новую версию записи.
Паттерн с CDC:
Приложение пишет только в БД — никаких вызовов к Redis.
CDC-коннектор (например, Debezium) транслирует изменения в топик Kafka (или непосредственно в поток).
Отдельный сервис-консьюмер слушает этот топик и обновляет Redis: либо удаляет старый ключ, либо перезаписывает новым значением.

Почему это решает проблему гонки:
Кэш обновляется асинхронно после записи в БД. Между ними нет синхронного окна, где другой запрос мог бы прочитать старый кэш.
События приходят в том же порядке, что и изменения (благодаря порядку в WAL).
Даже если консьюмер немного отстаёт, eventual consistency допустима для большинства сценариев (например, просмотр каталога товаров). Если нужна строгая согласованность, можно настроить синхронный режим чтения из БД при сомнении.

Реальный пример из практики:
В сервисе рекомендаций Netflix используется CDC для синхронизации PostgreSQL и Elasticsearch. При обновлении данных о фильме изменение попадает в Kafka через Debezium, а затем индексатор обновляет Elasticsearch. Это позволяет выдерживать миллионы запросов без блокировок.

Что должен зафиксировать аналитик:
«Для поддержания актуальности кэша использовать асинхронную синхронизацию через CDC».
«Допустимая задержка обновления кэша — не более 100 мс».
«При недоступности консьюмера кэш может быть временно неконсистентным, но это допустимо».

Почему не подходят другие варианты:
A (синхронное обновление в той же транзакции) — требует распределённой транзакции (2PC), что медленно и не масштабируется. К тому же в Redis нет транзакций с БД.
C (блокировка записи в кэш на время обновления) — создаёт узкое место, замедляет запись, не решает проблему чтения во время блокировки.
D (всегда читать из БД) — отказ от кэша, что убивает производительность.

Вывод: CDC — это золотой стандарт для поддержания консистентности между разнородными хранилищами в распределённых системах. Аналитик, включающий этот паттерн в требования, помогает команде избежать сложных и медленных синхронных решений.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4899 категория вопросов: #ARCHITECTURE
4899. В микросервисной системе один из сервисов (обработка изображений) потребляет много CPU и памяти, что иногда замедляет другие сервисы на том же узле. Какой паттерн изолирует ресурсы, чтобы сбой или перегрузка одного компонента не влияла на другие?
Anonymous Quiz
37%
Circuit Breaker
41%
Bulkhead
7%
Retry with backoff
15%
Event Sourcing
Объяснение:

📖 Подробное объяснение (из реальной практики):
Паттерн Bulkhead (переборка) заимствован из кораблестроения: водонепроницаемые отсеки не дают затопить всё судно. В IT это означает разделение ресурсов (потоки, память, CPU, сетевые соединения) между компонентами. Например, выделяются отдельные пулы потоков или отдельные контейнеры для разных сервисов. Если сервис обработки изображений перегружен, он использует только свой пул, а остальные сервисы продолжают работать.
Реальный пример: В Netflix Hystrix предоставляет реализацию bulkhead через разделение потоков. Это предотвращает эффект «каскадного отказа» при перегрузке одного компонента.

Что должен зафиксировать аналитик:
«Для каждого сервиса/компонента должны быть заданы лимиты ресурсов (CPU, память, потоки)».
«В случае исчерпания ресурсов одного компонента, другие должны продолжать работу».
Please open Telegram to view this post
VIEW IN TELEGRAM
№4900 категория вопросов: #SYSTEMDESIGN
4900. Координация изменений в DWH занимает недели, отделы не могут быстро внедрять свои фичи. Какой современный архитектурный подход предлагает децентрализованное владение данными, где каждый домен сам отвечает за свои дан
Anonymous Quiz
35%
Data Lakehouse
47%
Data Mesh
12%
Data Fabric
7%
Data Vault
Объяснение:

Проблема централизованного DWH:
В классическом подходе все данные стекаются в единое хранилище, управляемое одной центральной командой. При росте компании количество источников и потребителей растёт, требования к изменениям накапливаются, и центральная команда становится узким местом. Каждое изменение схемы требует согласований, тестирований и релизных циклов, что замедляет бизнес.

Что такое Data Mesh?
Термин введён Замком Дейгом (Zhamak Dehghani). Основные принципы:
Децентрализованное владение данными – каждый бизнес-домен (например, отдел продаж) сам управляет своими данными (создаёт, поддерживает, предоставляет).
Данные как продукт – каждый домен публикует свои данные в виде высококачественного, документированного, легко доступного продукта с чёткими соглашениями.
Самообслуживание – потребители (аналитики, другие домены) могут находить и использовать данные через каталог без посредников.
Федеративная управляемость (governance) – общие правила (качество данных, безопасность, согласование форматов) устанавливаются централизованно, но применяются децентрализованно.

Сравнение с другими вариантами:
A (Data Lakehouse) – объединяет озеро данных (дешёвое хранение) и хранилище (производительность запросов), но всё ещё централизованное.
C (Data Fabric) – архитектура, обеспечивающая интеграцию и управление данными с использованием активных метаданных, но часто тоже централизованная.
D (Data Vault) – модель данных для централизованного DWH, не про децентрализацию.

Реальный пример:
В крупном ритейлере переход на Data Mesh позволил команде маркетинга самостоятельно управлять данными о клиентах, а команде логистики – данными о поставках. Время вывода нового отчёта сократилось с 3 недель до 2 дней.

Что должен зафиксировать аналитик:
«Архитектура данных должна следовать принципам Data Mesh: доменное владение, данные как продукт, самообслуживание, федеративная governance».
«Каждый домен должен иметь свой стек для обработки данных (инструменты, хранилище), но с обязательными стандартами безопасности и качества».

Вывод: Data Mesh – это ответ на сложность централизованных DWH в больших организациях. Аналитик, знакомый с этим подходом, может предложить эффективную стратегию управления данными, ускоряющую бизнес-изменения.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4901 категория вопросов: #DBMS
4901. В legacy-системе вся бизнес-логика реализована в хранимых процедурах PostgreSQL. При попытке масштабирования системы возникают блокировки и ошибки параллелизма. Какой подход к размещению логики рекомендуется для микросервисной архитектуры?
Anonymous Quiz
5%
Перенести часть логики в триггеры
92%
Вынести бизнес-логику из БД на уровень микросервисов
2%
Увеличить мощность сервера БД
2%
Перейти на NoSQL базу данных
Объяснение:

Почему бизнес-логика в хранимых процедурах — это проблема для масштабирования?
Блокировки и взаимоблокировки (deadlocks) – длительные процедуры держат блокировки на таблицах, что при росте нагрузки увеличивает количество взаимоблокировок.

Ограниченное масштабирование – база данных вертикально масштабируется тяжелее, чем приложения. Добавить ещё один сервер с копией БД (read replica) не поможет, если логика пишет данные.
Сложность тестирования – хранимые процедуры сложно версионировать, тестировать изолированно и отлаживать по сравнению с кодом приложения.
Связанность с СУБД – миграция на другую БД становится практически невозможной.

Правильный подход для микросервисной архитектуры:
Логика должна жить в приложении (микросервисах), а база данных выполнять только функции хранения и атомарных операций (CRUD).
Использовать паттерн «Transaction Script» или Domain Model в коде, а не в процедурах.
Для сложных операций, требующих атомарности на уровне БД, использовать пессимистические блокировки или оптимистические блокировки (версионирование) на уровне кода, а не процедур.
При необходимости гарантировать согласованность между несколькими сервисами – использовать Saga (цепочка локальных транзакций с компенсациями) вместо монолитной транзакции.
Пример антипаттерна (в процедуре):
sql
CREATE PROCEDURE create_order(p_user_id INT, p_items JSONB) AS $$
BEGIN
-- проверка остатков, расчёт скидки, списание, создание заказа
-- всё в одной транзакции
END;
$$ LANGUAGE plpgsql;

Что делают в современных системах:
python
def create_order(user_id, items):
with db.transaction():
# проверка остатков (SELECT FOR UPDATE)
# расчёт скидки (в коде)
# создание заказа (INSERT)
# публикация события (Kafka)


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

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

Что должен зафиксировать аналитик:
«Бизнес-логика должна быть реализована на уровне приложения, а не в хранимых процедурах БД».
«База данных должна использоваться только для хранения данных и базовых атомарных операций».

Вывод: Хранимые процедуры — это инструмент для узкоспециализированных задач (например, массовые расчёты), но не для основной бизнес-логики в микросервисной архитектуре. Аналитик, понимающий это, поможет команде избежать архитектурного тупика при масштабировании.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4902 категория вопросов: #INTEGRATION
4902. Сервис А вызывает внешний API, который иногда возвращает ошибку 503. Если повторять запрос сразу, нагрузка на внешний сервис может только возрасти. Какая стратегия повторных попыток снижает нагрузку на внешний сервис и даёт ему время восстановиться?
Anonymous Quiz
6%
Повторять запрос сразу 5 раз с фиксированной задержкой 1 секунда
73%
Использовать экспоненциальную задержку с джиттером
9%
Повторять запрос только один раз через 10 секунд
12%
Не повторять запрос, а возвращать ошибку пользователю
Объяснение:

Проблема с немедленными повторами:
Если внешний API временно перегружен или восстанавливается после сбоя, множество клиентов, увидев ошибку, начнут повторять запросы одновременно. Это создаёт «шторм повторных попыток» (retry storm), который ещё сильнее перегружает сервис и затягивает его восстановление. Фиксированная задержка (например, 1 секунда) синхронизирует все повторы, создавая пиковые всплески нагрузки.

Что такое экспоненциальная задержка с джиттером:
Экспоненциальная задержка (Exponential Backoff) – интервал между повторами увеличивается в геометрической прогрессии: 1с, 2с, 4с, 8с, 16с. Это даёт внешнему сервису время на восстановление и разносит пики нагрузки во времени.
Джиттер (Jitter) – добавление случайного небольшого смещения (например, ±30%) к каждой задержке. Это предотвращает синхронизацию повторов от разных клиентов. Например: 1.2с, 2.5с, 3.8с, 9.1с вместо строгих 1, 2, 4, 8.
Пример реализации (Python):
python
import time, random

def call_with_retry(func, max_retries=5, base_delay=1):
for attempt in range(max_retries):
try:
return func()
except Exception:
if attempt == max_retries - 1:
raise
delay = (base_delay * (2 ** attempt)) + random.uniform(0, 0.5)
time.sleep(delay)

Сравнение с другими вариантами:
A (фиксированная задержка) – приводит к синхронизированным пикам нагрузки, создаёт retry storm.
C (единственный повтор через 10 секунд) – недостаточно надёжен для кратковременных сбоев, не даёт шансов на восстановление.
D (без повторов) – снижает надёжность системы, пользователь получает ошибку даже при временной проблеме.

Реальный пример:
AWS SDK для вызовов к S3 и DynamoDB реализует экспоненциальный backoff с джиттером по умолчанию. Stripe также рекомендует эту стратегию для обработки временных ошибок.

Что должен зафиксировать аналитик:
«При интеграции с внешними сервисами использовать повторные попытки с экспоненциальной задержкой и джиттером».
«Максимальное количество попыток — не более 5».
«После исчерпания попыток — помещать сообщение в Dead Letter Queue (DLQ) для ручного разбора».

Вывод: Экспоненциальный backoff с джиттером – это отраслевой стандарт для отказоустойчивых интеграций, предотвращающий перегрузку внешних систем и повышающий вероятность успешной обработки запроса.
Please open Telegram to view this post
VIEW IN TELEGRAM
Gemini vs ChatGPT: СМЕНА ФАВОРИТОВ ... вот что вышло 👇

* Все вокруг обсуждают ChatGPT, а я нашел альтернативу, которая реально качает — Gemini от Google. Пользуюсь и очень доволен.

Почему стоит попробовать:
✔️ Бесплатно (базовая версия)
✔️ Контекст 2 млн токенов — загружайте хоть целые кодобазы
✔️ Понимает текст, картинки, видео и аудио
✔️ Дружит с Google Диском, Gmail и календарем
✔️ Код пишет на уровне топ-моделей

Решил проверить его в деле — и не прогадал. Попросил Gemini найти для меня экспертные каналы по IT и AI, чтобы собрать чистое инфополе с нуля и не делать все вручную. Закинул ссылки на проверенных авторов, и нейросеть сама проанализировала сотни рекомендаций, отсеяв пустышки.

Результат — готовая подборка из 20+ каналов с реальным опытом по: AI-воркфлоу, автоматизации, вайб-кодингу, промт-инжинирингу, RAG-системам, нейрогенерации, крипте и др.

🔗 Забирайте список в один клик 👇
https://t.me/addlist/9wQJPILNMKNkNmNk

* Пишите в комменты — пробовали Gemini? Делитесь с друзьями впечатлениями и добавляйте подборку в свой актив 📌
🔥1🤔11
ИИ vs ЧЕЛОВЕК / AI УЖЕ МНОГОЕ УМЕЕТ, НО НЕ ТАК КАК ТЫ ...

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


⚠️ Технологии — это инструмент, а главное — это ты и твой живой контакт.

Приглашаем тебя в ЭКО-Пространство, где технологии — это фон, а главное — это ты и твой клиент ✔️ В этой ПОДБОРКЕ есть кое-что поважнее алгоритмов — ДОВЕРИЕ. В папке собраны каналы про экологичные продажи, про понимание, про рост без выгорания.

Пусть ИИ пишет тексты, а ты учись создавать отношения. 💚

Добавляй папку в свой актив и делись с друзьями! 📌
Ссылка ➡️ https://t.me/addlist/9wQJPILNMKNkNmNk
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
🔥1