Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
BA & SA | 10000 Interview questions
Kanalga Telegram’da o‘tish
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Ko'proq ko'rsatish📈 Telegram kanali BA & SA | 10000 Interview questions analitikasi
BA & SA | 10000 Interview questions (@systemanalystinterview) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 264 obunachidan iborat bo'lib, Karyera toifasida 3 852-o'rinni va Rossiya mintaqasida 63 593-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 264 obunachiga ega bo‘ldi.
24 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 382 ga, so‘nggi 24 soatda esa 45 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 3.60% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 2.47% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 369 marta ko‘riladi; birinchi sutkada odatda 253 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 1 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent объяснение, индекс, user_id, субд, паттерн kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 25 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Karyera toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
10 264
Obunachilar
+4524 soatlar
+317 kunlar
+38230 kunlar
Postlar arxiv
👩🏫Объяснение:
Гарантия Exactly-Once в распределенных системах достигается через идемпотентность. При идемпотентном API повторная отправка того же запроса с одинаковым уникальным ключом (idempotency key) не приводит к повторному списанию денег. Ваша система генерирует уникальный ID для каждого платежа и отправляет его в шлюз. Если ответ не получен (сбой сети) и вы отправляете запрос повторно с тем же ключом, шлюз распознает его как повтор и возвращает результат первоначальной операции. HTTP retry без идемпотентности приведет к двойному списанию. Очередь без подтверждения ненадежна. Сверка выписок — это постфактум, а не предотвращение дублей.
4514. При интеграции с внешним платежным шлюзом требуется гарантия, что каждый платежный запрос будет обработан ровно один раз (Exactly-Once), даже при сбоях сети. Какой механизм интеграции обеспечит это?
+2
Чат-боты под ключ за 3 дня
💻Проектируем сценарии под любые задачи в WhatsApp, Telegram, VK и MAX.
✅С ИИ и интерактивными кнопками.
⚡Опишите идею, мы оценим проект за 1 день и реализуем его под ключ.
👌От ТЗ до запуска.
Подать заявку
#реклама
chat2desk.com
О рекламодателе
👩🏫Объяснение:
Требуется мгновенная реакция на событие (списание товара), при этом складская система не может инициировать внешние вызовы. Решение — использовать Change Data Capture (CDC) паттерн. При изменении данных в БД склада (через триггеры или чтение логов транзакций) создается событие и помещается в очередь сообщений (Kafka, RabbitMQ). Система заказов подписывается на эту очередь и получает события в реальном времени. Это решает проблему: склад "не звонит" наружу, а только публикует события во внутреннюю очередь. Polling создаст задержку, прямой вызов невозможен по условию, ежедневная выгрузка не дает мгновенного обновления.
4513. Вам нужно спроектировать интеграцию между системой складского учета и системой заказов. Система заказов должна мгновенно получать информацию о товарах со склада. Складская система не может вызывать внешние API. Какой подход наиболее эффективен?
👩🏫Объяснение:
Паттерн Pub/Sub (Издатель-Подписчик) через брокер сообщений (например, RabbitMQ с Exchange типа Fanout, или Apache Kafka с топиками) решает эту задачу оптимально. Основная система (издатель) публикует сообщение один раз в брокер. Брокер гарантированно (персистентные очереди, подтверждения доставки) доставляет копию этого сообщения в отдельную очередь для каждого из трех сервисов-подписчиков. Если один сервис упал, его сообщения будут ждать в его очереди, не влияя на доставку другим. Это надежно, масштабируемо и обеспечивает слабую связность. Point-to-point сложно поддерживать, ESB избыточен, прямая запись в БД нарушает инкапсуляцию и ненадежна.
4512. Вам нужно обеспечить надежную доставку критичных финансовых сообщений из основной системы в три разные целевые системы. Сообщение не должно быть потеряно даже при сбое любой из систем. Какую топологию интеграции выбрать?
А7 — быстрые международные платежи с надежностью банка
👍Платежи в любую точку мира
💰 В любой валюте
😊Комиссия 0,3%. Конвертация по курсу ЦБ
📅Закрывающие документы для бухгалтерии
Работайте с партнерами по всему миру без задержек и переплат!
Перейти на сайт
Финансовые услуги оказывает: ПАО "Банк ПСБ".
#реклама
a7-agent.ru
О рекламодателе
👩🏫Объяснение:
Это паттерн "Кеширование на стороне потребителя" в сочетании с событийным драйвом. Сервис "Заказы" хранит локальную копию (кеш) часто используемых данных о клиентах. Когда в сервисе "Клиенты" данные меняются, он публикует событие (через брокер, например, Kafka). Сервис "Заказы" подписан на эти события и асинхронно обновляет свой кеш. Преимущества: 1) Нет синхронных вызовов при обработке заказа → высокая производительность и доступность (работает даже при падении сервиса "Клиенты"). 2) Слабая связь через события. Прямой вызов создает жесткую связь и точку отказа. Копирование всей БД или общая БД нарушают границы микросервисов.
4511. В микросервисной архитектуре сервису "Заказы" нужны данные о клиенте из сервиса "Клиенты". Как минимизировать прямую жесткую связь и повысить отказоустойчивость?
👩🏫Объяснение:
gRPC — современный фреймворк для удаленного вызова процедур, который идеально подходит под требования: 1) Бинарный протокол (Protocol Buffers) — значительно эффективнее текстового JSON/XML по размеру и скорости сериализации. 2) Работает поверх HTTP/2 — поддерживает мультиплексирование запросов (снижает задержки), бинарные фреймы и потоковую передачу данных (streaming). 3) Автоматическая генерация кода для клиента и сервера. REST/JSON — стандарт де-факто, но не самый эффективный. SOAP/XML — громоздкий и устаревший для мобильных приложений. FTP — для передачи файлов, не для API.
4510. Вы выбираете протокол для интеграции мобильного приложения с бэкендом. Нужна минимальная задержка, бинарная эффективная передача и поддержка потоковых данных. Что вы выберете?
👩🏫Объяснение:
Это классический паттерн "Фоновая задача/очередь заданий". Основная система быстро создает задачу ("отправить email пользователю X") и записывает ее в надежное хранилище (таблицу в БД или в очередь в Redis). Отдельный фоновый процесс (воркер) постоянно опрашивает это хранилище, берет задачи и выполняет их, вызывая внешний Email-сервис. Это развязывает основную систему от медленной операции: пользователь получает ответ мгновенно, а email уходит когда сможет. Это проще и часто надежнее для подобных фоновых задач, чем настройка полноценного Kafka. Синхронный вызов будет блокировать систему, веб-сокеты здесь не применимы.
4509. Система должна отправлять маркетинговые email тысячам пользователям. Отправка через внешний Email-сервис занимает время. Как спроектировать интеграцию, чтобы не блокировать основной поток работы системы?
