4639. Вы проектируете интеграцию нового мобильного приложения с устаревшей ERP-системой. Система старая, медленная, её API нестабилен. Требование: пользователь не должен «видеть» задержки при отправке заказа. Какой подход выберете?
Anonymous Quiz
8%
Прямой синхронный REST-вызов из приложения в ERP при нажатии кнопки.
81%
Асинхронная отправка заказа через надежную очередь сообщений с мгновенным подтверждением приложению.
7%
Регулярная пакетная выгрузка файлов с заказами на FTP-сервер ERP.
4%
Предложить модернизировать ERP, так как интеграция невозможна.
👩🏫Объяснение:
Ключевое требование — пользователь не должен ждать. Прямой вызов (1) приведет к таймаутам и ошибкам в приложении. Решение с очередью позволяет принять заказ, сразу подтвердить пользователю («Заказ принят в обработку»), а затем в фоне надежно доставлять его в ERP, переотправляя при сбоях. Пакетная выгрузка (3) нарушит требование оперативности. Вариант (4) часто нереалистичен из-за бюджета и сроков.
4640. Есть две critical-системы: «Касса» (фискальные операции) и «Склад» (учет остатков). Списание товара должно быть атомарным: если товар списан в «Кассе», он обязан быть списан на «Складе», и наоборот. Как обеспечить консистентность данных?
Anonymous Quiz
48%
Использовать распределенную транзакцию (2PC) между системами.
34%
Внедрить паттерн «Отправка событий» с подпиской «Склада» на события продаж из «Кассы».
3%
Реализовать периодическое выравнивание остатков по расписанию раз в час.
15%
Создать общую базу данных, к которой будут обращаться обе системы.
👩🏫Объяснение:
2PC (1) в распределенных системах — антипаттерн, снижающий доступность. Общая БД (4) создаст монолит и проблемы масштабирования. Выравнивание по расписанию (3) дает расхождения до часа, что неприемлемо. Event Sourcing обеспечивает надежную асинхронную передачу события о продаже. «Склад» гарантированно его обработает, возможно, с небольшой задержкой, но консистентность в конечном счете будет достигнута.
🤔2
4641. Компания купила 5 SaaS-сервисов. Каждый имеет свои API, форматы данных, токены доступа. Нужно построить единый каталог товаров, агрегируя данные из всех источников. Какой архитектурный компонент будет ключевым?
Anonymous Quiz
16%
Message Broker (Kafka) для потоковой передачи данных.
10%
Прямые Point-to-Point интеграции между каждым SaaS и системой-агрегатором.
5%
Единая база данных, куда все SaaS будут писать напрямую.
68%
Интеграционная шина/платформа (ESB/IPaaS) с гибкими конвейерами преобразования данных (ETL).
👩🏫Объяснение:
Проблема — управление множеством разнородных, меняющихся API. ESB/IPaaS централизует интеграцию, предоставляя инструменты для трансформации данных, маршрутизации и адаптации к изменениям в одном месте. Point-to-Point создаст хаос при любом изменении источника. Message Broker — транспорт, но не решит проблему преобразования форматов.
❤1
4642. В системе лояльности при списании бонусов нужно одновременно: 1) обновить баланс в БД, 2) отправить пуша уведомление, 3) записать аудит-лог в Elasticsearch. Как обеспечить надежность без серьезных потерь производительности?
Anonymous Quiz
54%
Записать в БД и сразу отправить событие в брокер, чтобы отдельные подписчики отправили пуш.
33%
Выполнять все три действия последовательно в одной транзакции.
1%
Полностью положиться на ретраи и повторы при ошибках в каждом из действий.
12%
Использовать отложенные задачи (cron) для отправки уведомлений и записи логов раз в 5 минут.
👩🏫Объяснение:
Это классический паттерн «транзакция выхода из базы данных». Основная транзакция (списание) завершается быстро и надежно. Дополнительные, менее критические действия (пуш, лог) выполняются асинхронно другими потребителями, что не блокирует пользователя. Последовательное выполнение замедлит операцию и сделает её уязвимой. Cron нарушает требование оперативности. Ретраи без асинхронности приведут к таймаутам для пользователя.
4643. Нужно интегрировать он-премис CRM с облачным ML-сервисом для прогноза оттока. ML-сервис требует больших объемов данных для обучения, но работает с задержкой. Какой тип интеграции оптимален?
Anonymous Quiz
10%
Синхронный REST API вызов к ML-сервису при открытии карточки клиента.
26%
Настроить постоянную репликацию базы данных CRM в базу ML-сервиса.
64%
Регулярная выгрузка данных из CRM в облачное хранилище и отдельная асинхронная загрузка.
0%
Отказаться от интеграции, так как задержка ML недопустима.
👩🏫Объяснение:
Это кейс для ETL/ELT, а не для реального времени. Синхронный вызов убьет производительность интерфейса CRM. Репликация всей БД может быть избыточной и небезопасной. Пакетная выгрузка в Data Lake решает задачу передачи больших данных для обучения. Прогнозы, которые обновляются раз в сутки, затем загружаются в CRM — это практичный компромисс между ценностью данных и производительностью.
4644. Вы делаете систему для агрегации данных о транспорте. Десятки тысяч устройств шлют координаты каждые 10 секунд. Нужно сохранять их, строить маршруты и считать метрики в реальном времени. Какую технологию выберете для приема потока данных?
Anonymous Quiz
4%
Классическая реляционная БД (PostgreSQL) с REST API.
61%
Потоковая платформа (Apache Kafka, Apache Pulsar).
20%
Хранилище файлов (S3) с загрузкой пакетов по протоколу SFTP.
14%
Очередь сообщений (RabbitMQ) в режиме «очередь задач».
👩🏫Объяснение:
Это типичный use case для high-throughput потоковых данных. Kafka создана для приема, буферизации и распределения огромных потоков событий с малой задержкой. REST + PG не справятся с нагрузкой и частотой записей. RabbitMQ — хорошая очередь, но не оптимизирована для long-running потоковой обработки и хранения логов. Пакетная загрузка в S3 не соответствует требованию «реального времени».
4645. При обновлении заказа в системе «Заказы» нужно уведомить систему «Доставка». Очень важно не потерять ни одного события, даже если «Доставка» легла на техобслуживание. Какой паттерн гарантирует доставку?
Anonymous Quiz
2%
HTTP-колбэк с 3 ретраями.
12%
Периодический опрос «Доставки» на наличие новых заказов.
11%
Запись события в локальный лог-файл системы «Заказы».
75%
Подтвержденное получение через persistent очередь сообщений.
👩🏫Объяснение:
Ключ — гарантия доставки при нестабильности получателя. Очередь (брокер) надежно хранит сообщение, пока система-получатель не обработает его и не подтвердит (ACK). Без подтверждения сообщение возвращается в очередь. HTTP-ретраи не помогут, если получатель недоступен долго. Лог-файл не является механизмом интеграции. Опрос неэффективен и создает задержки. Только очередь обеспечивает надежный асинхронный обмен.