Available now! Telegram Research 2025 — the year's key insights 
BA & SA | 10000 Interview questions
Open in Telegram
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Show more📈 Analytical overview of Telegram channel BA & SA | 10000 Interview questions
Channel BA & SA | 10000 Interview questions (@systemanalystinterview) in the Russian language segment is an active participant. Currently, the community unites 10 207 subscribers, ranking 3 867 in the Career category and 63 966 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 207 subscribers.
According to the latest data from 22 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 322 over the last 30 days and by -2 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 3.52%. Within the first 24 hours after publication, content typically collects 2.53% reactions from the total number of subscribers.
- Post reach: On average, each post receives 359 views. Within the first day, a publication typically gains 258 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 2.
- Thematic interests: Content is focused on key topics such as объяснение, индекс, user_id, субд, паттерн.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7”
Thanks to the high frequency of updates (latest data received on 23 June, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Career category.
10 207
Subscribers
-224 hours
+27 days
+32230 days
Posts Archive
4635. Что из перечисленного является основной функцией Service Mesh в контексте интеграции микросервисов?
👩🏫Объяснение:
Protocol Buffers (protobuf) — это бинарный формат сериализации данных, разработанный Google. Он компактнее и быстрее JSON/XML, использует строгую типизацию через .proto-файлы. Широко используется в gRPC для высокопроизводительных RPC-вызовов между микросервисами благодаря эффективной кодировке и поддержке потоковой передачи.
4634. Какой формат сериализации данных использует бинарную кодировку и часто применяется в высокопроизводительных RPC-фреймворках?
👩🏫Объяснение:
Паттерн "Цепочка сервисов" предполагает последовательный вызов сервисов, где результат одного сервиса передается следующему. Это создает синхронную цепочку зависимостей. Пример: сервис заказов вызывает сервис валидации, затем сервис платежей, затем сервис уведомлений. Недостаток — увеличение общего времени отклика и риск каскадных сбоев.
4633. Какой паттерн интеграции используется, когда система А вызывает систему Б, которая затем вызывает систему В, и результат возвращается по цепочке обратно?
👩🏫Объяснение:
Прокси-сервер выступает в роли промежуточного звена между клиентом и сервером, скрывая внутреннюю структуру сети и обеспечивая дополнительные функции: кэширование, аутентификацию, трансформацию запросов. В интеграциях обратный прокси (reverse proxy) часто используется для маршрутизации запросов к внутренним сервисам без прямого доступа клиентов к ним.
4632. Какой механизм позволяет системе А отправлять запросы системе Б через промежуточный сервер, который скрывает сетевую структуру внутренней системы?
👩🏫Объяснение:
AMQP (Advanced Message Queuing Protocol) — это открытый стандартный протокол прикладного уровня для асинхронной передачи сообщений между системами. Он поддерживает модель публикации-подписки (pub/sub) и гарантирует доставку сообщений даже при временных сбоях.
🔍 Ключевые особенности AMQP:
Гарантии доставки:
At-most-once (максимум один раз)
At-least-once (минимум один раз)
Exactly-once (ровно один раз) — через механизмы идемпотентности
Модели обмена:
Очереди (Queues): Точечная доставка
Топики/Exchange (Topics): Публикация-подписка
RPC: Запрос-ответ
Надежность:
Подтверждение получения (acknowledgments)
Сохранение сообщений на диск
Транзакционность
💡 Как работает AMQP в интеграциях:
Архитектурные компоненты:
Producer/Publisher: Отправитель сообщений
Exchange: Маршрутизатор сообщений
Queue: Очередь сообщений
Consumer/Subscriber: Получатель сообщений
Пример потока:
```text
Producer → [Exchange] → [Binding Rules] → [Queue] → Consumer
↓ ↓
(по routing key) (сохраняется до обработки)
```
🎯 Реализации AMQP:
RabbitMQ — самая популярная реализация
```python
# Пример публикации сообщения в RabbitMQ
channel.basic_publish(
exchange='orders',
routing_key='new.order',
body=json.dumps(order_data),
properties=pika.BasicProperties(
delivery_mode=2, # Сохранять на диск
)
)
Apache Qpid
```
Azure Service Bus (частичная поддержка AMQP)
🔥 Практические сценарии использования:
Сценарий 1: Обработка заказов в e-commerce
Пользователь создает заказ → сообщение в очередь new_orders
Сервис валидации, сервис платежей, сервис склада подписываются на очередь
Каждый сервис обрабатывает заказ независимо
Если сервис платежей временно недоступен, сообщение остается в очереди
Сценарий 2: Сбор логов и метрик
Все сервисы публикуют логи в exchange logs
Exchange маршрутизирует логи в разные очереди по severity
Сервис мониторинга и сервис аналитики подписываются на нужные очереди
Сценарий 3: Фоновая обработка задач
Пользователь загружает видео → сообщение в очередь video_processing
Воркеры берут задачи из очереди и обрабатывают
Можно масштабировать количество воркеров по нагрузке
⚡️ Преимущества AMQP:
Надежность:
Сообщения сохраняются на диск
Подтверждение получения
Автоматическое восстановление соединений
Гибкость маршрутизации:
Direct (точная маршрутизация по ключу)
Fanout (всем подписчикам)
Topic (по шаблону ключа)
Headers (по заголовкам сообщения)
Управление потоком:
QoS (Quality of Service) — ограничение неподтвержденных сообщений
Поддержка backpressure
Кластеры и отказоустойчивость:
Репликация очередей между узлами
Автоматическое переподключение при сбоях
⚠️ Сложности и решения:
Проблема: Гарантированный порядок доставки
Решение: Использовать одну очередь на потребителя или механизмы sequencing
Проблема: Накопление сообщений при сбое потребителя
Решение: Dead Letter Queues (DLQ) + алертинг
Проблема: Персистентность vs производительность
Решение: Балансировать между delivery_mode=1 (transient) и delivery_mode=2 (persistent)
👨💼 Роль системного аналитика:
Проектирование топологии обмена сообщениями:
Какие exchange, очереди и routing keys нужны?
Какие bindings между ними?
Определение требований к доставке:
Нужны ли гарантии exactly-once?
Какие таймауты и retry политики?
Как обрабатывать poison messages?
Проектирование форматов сообщений:
```json
{
"message_id": "uuid",
"timestamp": "2024-01-15T10:30:00Z",
"type": "order.created",
"version": "1.0",
"payload": {...},
"metadata": {...}
}
```
Планирование мониторинга:
Длина очередей
Latency обработки сообщений
Rate публикации/потребления
4631. Какой протокол обмена сообщениями использует модель "публикация-подписка" (pub/sub) и гарантирует доставку сообщений даже при временной недоступности получателя?
👩🏫Объяснение:
Кэширование — это механизм хранения копии данных в быстродоступном хранилище, чтобы ускорить получение этих данных при повторных запросах и снизить нагрузку на первичный источник.
🔍 Простая аналогия:
Представьте библиотеку:
Первичный источник: Книгохранилище в подвале (медленно)
Кэш: Полка на абонементе (быстро)
Библиотекарь: Сначала проверяет полку, если книги нет — идет в хранилище
💡 Как кэширование работает в интеграциях:
Без кэша:
```text
Клиент → Запрос → Сервис → [Сложный расчет/Запрос к БД] → Ответ
↑ (каждый раз заново!) ↓
└─────────────────────────────────────────────────────┘
С кэшем:
text
Клиент → Запрос → Сервис → [Проверка кэша]
↓
[Данные в кэше?] → Да → Возврат из кэша (быстро!)
↓ Нет
[Выполнение запроса к источнику]
↓
[Сохранение в кэш] → Возврат клиенту
```
🎯 Типы кэширования в интеграциях:
Кэш на стороне клиента:
Браузер кэширует статические ресурсы (CSS, JS, изображения)
Mobile app кэширует данные локально
Срок жизни: от часов до дней
Кэш на стороне сервера:
```nginx
# Пример настройки кэширования в Nginx
location /api/products {
proxy_cache products_cache;
proxy_cache_valid 200 5m; # Кэшировать успешные ответы 5 минут
proxy_pass http://product-service;
}
Распределенный кэш:
Redis, Memcached, Hazelcast
Общий кэш для всех экземпляров сервиса
```
Пример использования:
```java
// Spring Cache с Redis
@Cacheable(value = "products", key = "#id")
public Product getProduct(String id) {
return productRepository.findById(id); // Дорогой запрос к БД
}
```
⚡️ Стратегии кэширования:
Cache-Aside (Lazy Loading):
Проверить кэш → если нет → получить из источника → сохранить в кэш
Самый распространенный подход
Write-Through:
Запись сначала в кэш, затем в источник
Гарантирует актуальность данных
Write-Behind:
Запись сначала в кэш, затем асинхронно в источник
Высокая производительность записи
🔥 Практические примеры:
Пример 1: Кэширование справочников
Города, валюты, типы документов
Меняются редко, запрашиваются часто
Можно кэшировать на 24 часа
Пример 2: Кэширование результатов сложных расчетов
Аналитические отчеты
Рекомендательные алгоритмы
Кэшировать на 1 час или до изменения исходных данных
Пример 3: Кэширование сессий пользователей
Информация о пользователе после логина
Сохранять в Redis с TTL 30 минут
⚠️ Проблемы и решения:
Проблема: Устаревшие данные (Stale Data)
Решение:
Инвалидация кэша при изменении данных
TTL (Time-To-Live) — автоматическое удаление старых записей
Версионирование ключей кэша
Проблема: "Пробоина кэша" (Cache Miss Storm)
Решение:
Предзагрузка популярных данных
Использование "теплого" кэша
Блокировка (Locking) при первом запросе
👨💼 Что должен учитывать системный аналитик:
Определять кандидатов на кэширование:
Какие данные читаются чаще, чем изменяются?
Какие запросы самые дорогие по времени/ресурсам?
Проектировать стратегию инвалидации:
Как узнавать об изменениях данных?
Нужна ли синхронная инвалидация или можно по TTL?
Определять требования к актуальности:
"Данные должны быть актуальны в течение 5 минут"
"Допустима задержка до 1 часа для аналитических данных"
Учитывать объемы данных:
Сколько памяти потребуется?
Нужен ли distributed кэш?
4630. Какой механизм позволяет временно хранить результаты запросов и быстро возвращать их при повторных обращениях, уменьшая нагрузку на источник данных?
👩🏫Объяснение:
Паттерн "Database per Service" (База данных на сервис) — это фундаментальный принцип микросервисной архитектуры, при котором каждый сервис управляет своей собственной базой данных, и другие сервисы могут получать доступ к этим данным только через публичный API сервиса-владельца.
🔍 Почему это важно в современных архитектурах:
Старый подход (антипаттерн): Общая база данных
Все сервисы пишут и читают из одной БД
Изменение схемы БД ломает несколько сервисов сразу
Невозможно выбрать оптимальную СУБД для каждой задачи
Нарушается принцип инкапсуляции
Новый подход: Database per Service
text
Сервис Заказов Сервис Платежей Сервис Каталога
↓ ↓ ↓
[БД Заказов] [БД Платежей] [БД Товаров]
MySQL PostgreSQL MongoDB
💡 Ключевые принципы:
Владение данными: Каждый сервис — единственный владелец своих данных
Инкапсуляция: Детали хранения данных скрыты внутри сервиса
API как контракт: Доступ к данным только через четко определенный API
Независимое развертывание: Можно обновлять схему БД одного сервиса, не затрагивая другие
🎯 Преимущества подхода:
Независимость технологий:
Сервис Заказов может использовать реляционную БД (MySQL)
Сервис Аналитики — колоночную (ClickHouse)
Сервис Рекомендаций — графовую (Neo4j)
Масштабируемость:
Каждую БД можно масштабировать независимо
Можно шардировать БД по бизнес-доменам
Отказоустойчивость:
Падение одной БД не влияет на другие сервисы
Можно настроить репликацию для каждой БД отдельно
Гибкость развития:
Можно менять схему БД внутри сервиса без согласования с другими командами
Легче рефакторить и оптимизировать
⚡️ Вызовы и решения:
Проблема: Как обеспечить согласованность данных между сервисами?
Решение: Паттерн Сага (Saga) для распределенных транзакций
Проблема: Как выполнять сложные запросы, требующие данных из нескольких сервисов?
Решение:
API Composition: Агрегация данных на уровне API Gateway
Командное разделение ответственности (CQRS): Отдельные модели для чтения и записи
Денормализованные копии данных: Репликация нужных данных в другой сервис через события
👨💼 Практический пример от аналитика:
Требование: "При отображении страницы товара нужно показывать: основную информацию, наличие на складе, отзывы и рейтинг."
Реализация:
Сервис Каталога (владеет основной информацией о товаре)
Сервис Склада (владеет информацией о наличии)
Сервис Отзывов (владеет отзывами и рейтингами)
API Gateway делает параллельные вызовы ко всем трем сервисам и агрегирует результат
4629. Какой подход к интеграции предполагает, что каждая система работает со своей собственной базой данных, а обмен данными происходит только через API?
