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-ретраи не помогут, если получатель недоступен долго. Лог-файл не является механизмом интеграции. Опрос неэффективен и создает задержки. Только очередь обеспечивает надежный асинхронный обмен.
4646. Вы проектируете схему БД для интернет-магазина. Товар может принадлежать нескольким категориям, и каждая категория может содержать множество товаров. Как правильно смоделировать связь «многие ко многим»?
Anonymous Quiz
2%
Добавить поле category_id в таблицу products.
8%
Добавить поле product_id в таблицу categories.
87%
Создать отдельную таблицу-связку product_categories с внешними ключами.
2%
Хранить список ID категорий в текстовом поле товара.
👩🏫Объяснение:
Связь «многие ко многим» не может быть реализована через одно внешнее ключевое поле в одной из таблиц. Это нарушит нормализацию и приведет к проблемам с целостностью и обновлением данных. Отдельная таблица product_categories хранит пары (product_id, category_id), что позволяет гибко добавлять и удалять связи. Хранение списков в текстовом поле (вариант 4) — это антипаттерн, делающий выборку и агрегацию крайне неэффективной.
4647. В системе участились жалобы на медленную выборку пользователей по email. Поле email уже проиндексировано. В чем может быть причина, если запрос ищет по полному совпадению (WHERE email = 'user@domain.com')?
Anonymous Quiz
9%
Индексы не работают для текстовых полей
64%
В таблице накопилось большое количество «мертвых» записей (bloat) из-за частых обновлений и удалений
6%
Необходимо сменить тип поля с VARCHAR на TEXT
22%
Следует создать дополнительный индекс по полю id
👩🏫Объяснение:
Индексы по текстовым полям прекрасно работают для операций равенства. Однако, если в таблице интенсивно происходит UPDATE или DELETE, физические страницы индекса и таблицы фрагментируются. Это заставляет СУБД читать много пустых или полупустых страниц, чтобы найти нужные строки. Решением является периодическая процедура обслуживания (например, VACUUM FULL в PostgreSQL или перестройка индекса). Смена типа данных или лишний индекс не решат эту проблему производительности.