Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
BA & SA | 10000 Interview questions
Відкрити в Telegram
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Показати більше📈 Аналітичний огляд Telegram-каналу BA & SA | 10000 Interview questions
Канал BA & SA | 10000 Interview questions (@systemanalystinterview) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 10 207 підписників, посідаючи 3 867 місце в категорії Кар'єра та 63 966 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 207 підписників.
За останніми даними від 22 червня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 322, а за останні 24 години на -2, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 3.52%. Протягом перших 24 годин після публікації контент зазвичай збирає 2.53% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 359 переглядів. Протягом першої доби публікація в середньому набирає 258 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 2.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як объяснение, индекс, user_id, субд, паттерн.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7”
Завдяки високій частоті оновлень (останні дані отримано 23 червня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Кар'єра.
10 207
Підписники
-224 години
+27 днів
+32230 день
Архів дописів
👩🏫Объяснение:
Backpressure (обратное давление) — это механизм контроля потока данных в системах, где производитель генерирует данные быстрее, чем потребитель может их обработать.
Проблема без Backpressure:
Производитель отправляет 10 000 сообщений/сек
Потребитель обрабатывает только 1 000 сообщений/сек
Очередь переполняется → память заканчивается → система падает
Как работает Backpressure:
Обнаружение перегрузки:
Потребитель отслеживает свою загрузку
При достижении лимита (например, 80% CPU или полная очередь) активируется backpressure
Сигнализация производителю:
Через протокол (TCP window size)
Через механизмы реактивных потоков (Reactive Streams: request(n))
Через метрики (Kafka consumer lag)
Реакция производителя:
Временная остановка отправки
Уменьшение скорости
Буферизация на своей стороне
Пример из реальной жизни:
Представьте конвейер на заводе:
Рабочий №1 быстро кладет детали на ленту
Рабочий №2 не успевает их обрабатывать
Рабочий №2 кричит: «Стоп! Я не успеваю!»
Рабочий №1 приостанавливает работу
Технические реализации:
TCP: Window size — получатель сообщает, сколько данных готов принять
Reactive Streams (RxJava, Project Reactor):
```
java
// Потребитель запрашивает определенное количество элементов
subscription.request(10); // "Дай мне 10 элементов"
Apache Kafka: Consumer offset lag — отставание потребителя от производителя
```
4623. Какой механизм позволяет получателю сообщений сигнализировать отправителю о необходимости снизить скорость отправки?
👩🏫Объяснение:
API Gateway — это специализированный сервер, который выступает в роли единого фасада для всех внешних клиентов (мобильных приложений, браузеров, партнерских систем).
Основные функции API Gateway:
🔐 Аутентификация и авторизация:
Проверка API-ключей, JWT-токенов, OAuth
Определение прав доступа для каждого клиента
Пример: Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
🛣 Роутинг и версионирование:
Маршрутизация запросов к нужному внутреннему сервису
Поддержка разных версий API
Пример: /api/v1/orders → сервис заказов, /api/v2/orders → новая версия
⚡️ Ограничение скорости (Rate Limiting):
Защита от DDoS-атак и злоупотреблений
Квотирование по клиентам (например, 1000 запросов/час)
Пример: X-RateLimit-Limit: 1000, X-RateLimit-Remaining: 950
🔄 Агрегация данных:
Объединение ответов нескольких сервисов в один
Пример: данные о заказе + данные о доставке + данные о клиенте
📊 Мониторинг и аналитика:
Сбор метрик по всем запросам
Логирование для аудита и отладки
Архитектурный контекст:
```
text
Внешний клиент (мобильное приложение)
↓
API Gateway ←─ Здесь аутентификация, rate limiting
↓
┌──────┴──────┐
↓ ↓
Сервис Сервис
Заказов Платежей
```
4622. Какой компонент служит единой точкой входа для внешних клиентов и управляет аутентификацией, роутингом и ограничением запросов?
👩🏫Объяснение:
Change Data Capture (CDC) — это паттерн интеграции, который отслеживает изменения в базе данных (INSERT, UPDATE, DELETE) и передает их другим системам почти в реальном времени.
Как работает CDC:
Чтение журнала транзакций:
Каждая СУБД ведет журнал: WAL в PostgreSQL, binlog в MySQL, redo log в Oracle
В этот журнал записывается все, что происходит с данными
CDC-агент (например, Debezium) читает этот журнал
Преобразование в события:
```json
{
"op": "u", // операция: u=update, c=create, d=delete
"before": {"id": 1, "name": "Старое имя"},
"after": {"id": 1, "name": "Новое имя"},
"source": {"table": "users", "db": "main"}
}
```
Отправка в шину событий:
События публикуются в Kafka, RabbitMQ или другую очередь
Другие сервисы подписываются на эти события
Где применяется:
Синхронизация кэшей: При изменении товара в БД → обновление кэша в Redis
Аналитика в реальном времени: События сразу попадают в ClickHouse для отчетов
Уведомления: При создании заказа → отправка email клиенту
Поисковые индексы: Обновление Elasticsearch при изменении данных
4621. Какой паттерн используется для чтения изменений данных из журнала транзакций БД в реальном времени?
👩🏫Объяснение:
Change Data Capture (CDC) — это современный, эффективный паттерн интеграции, который кардинально меняет подход к синхронизации данных между системами.
Как работает (упрощенно):
1. Каждая серьезная СУБД (PostgreSQL, MySQL, Oracle) ведет журнал транзакций (Write-Ahead Log, WAL; binlog). Это низкоуровневая последовательность всех операций изменения данных (INSERT, UPDATE, DELETE), записанная перед их фактическим применением к таблицам. Цель СУБД — обеспечение согласованности и восстановление после сбоев.
2. CDC-агент (например, Debezium) подключается к СУБД не как обычное приложение, а читает этот журнал транзакций.
3. Агент превращает низкоуровневые записи журнала в удобные, структурированные события (например, { "op": "c", "after": { "id": 123, "name": "New Product" } }).
4. Эти события публикуются в шину событий (чаще всего Apache Kafka).
Практическое применение для системного аналитика:
1. Актуализация кэшей и поисковых индексов: При изменении товара в основной БД, событие через CDC мгновенно отправляется в Elasticsearch для обновления поискового индекса.
2. Построение агрегированных витрин данных: События из операционной БД стримятся в систему аналитики (например, ClickHouse) для построения актуальных отчетов.
3. Микросервисная синхронизация: Сервис «Заказы» и сервис «Доставка» имеют свои БД. При создании заказа, событие через CDC уведомляет сервис «Доставка», что нужно планировать доставку. Это альтернатива прямому вызову API.
4. Аудитинг и compliance: Полный поток всех изменений данных можно сохранять для целей аудита.
Роль аналитика: При проектировании систем, где критична актуальность данных или требуется реагирование на изменения, предлагать рассмотреть CDC как более эффективную и надежную альтернативу традиционному опросу (polling) по расписанию.
4620. Какой механизм используется для изоляции сообщений, которые не могут быть обработаны после нескольких попыток?
👩🏫Объяснение:
gRPC (Google Remote Procedure Call) — это современный высокопроизводительный фреймворк для удаленного вызова процедур, разработанный Google.
Ключевые особенности:
Protocol Buffers (protobuf):
Бинарный формат (в отличие от текстового JSON/XML)
Занимает меньше места, быстрее сериализуется/десериализуется
Строгая типизация через .proto файлы
Пример определения:
protobuf
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
HTTP/2:
Мультиплексирование (несколько запросов в одном соединении)
Сжатие заголовков
Server push (сервер может отправлять данные без запроса)
Типы взаимодействия:
Унарный (один запрос — один ответ)
Стриминг (потоковая передача в обе стороны)
Клиентский или серверный стриминг
Где применяется:
Внутренняя коммуникация микросервисов
Системы реального времени (чат, уведомления)
Когда важны производительность и низкая задержка4619. Какой протокол использует бинарный формат Protocol Buffers и HTTP/2 для высокопроизводительной интеграции?
👩🏫Объяснение:
Point-to-Point (P2P, «точка-точка») — это самый простой подход к интеграции, при котором две системы соединяются напрямую, без посредников.
Как это работает:
Система A знает точный адрес и протокол системы B
Отправляет данные напрямую (например, через HTTP-вызов или прямой доступ к БД)
Система B принимает и обрабатывает запрос
Пример: Мобильное приложение вызывает REST API бэкенда напрямую.
Плюсы:
Простота начальной реализации
Минимальная задержка (нет промежуточных звеньев)
Минусы (и почему это часто антипаттерн):
При добавлении третьей, четвертой системы количество связей растет экспоненциально
Создает «спагетти-архитектуру», которую невозможно поддерживать
Нет централизованного управления, логирования, мониторинга
Высокая связанность: изменение в одной системе требует изменений во всех связанных
4618. Какой подход позволяет системам обмениваться данными напрямую, без промежуточных компонентов?
👩🏫Объяснение:
Dead Letter Queue (DLQ, очередь «мертвых писем») — это специальная очередь в системах обмена сообщениями для сообщений, которые не удалось обработать.
Как это работает — пошагово:
Сообщение поступает в основную очередь
Потребитель пытается его обработать → возникает ошибка
Повторные попытки (Retry): Система делает несколько попыток (например, 3-5 раз)
Если все попытки провалились → сообщение перемещается в DLQ
Инженеры анализируют сообщения в DLQ, находят причину ошибки
После исправления сообщения можно вернуть в основную очередь
Причины попадания в DLQ:
Неверный формат данных в сообщении
Ошибка валидации (например, отсутствует обязательное поле)
Временная недоступность зависимого сервиса
Баг в коде потребителя
Пример из жизни:
Представьте почтовое отделение. Если письмо нельзя доставить (неверный адрес, получатель умер), его не выбрасывают, а кладут в специальную папку «неврученная почта» для дальнейшего разбора.
Почему это важно:
Предотвращает зацикливание: «Отравленные» сообщения не блокируют очередь
Упрощает отладку: Все проблемные сообщения в одном месте
Позволяет восстановление: После исправления ошибки данные не теряются
