4712. В системе обрабатываются заказы. Из-за временного сбоя сети некоторые сообщения о новых заказах были отправлены повторно. Что нужно предусмотреть в архитектуре интеграции, чтобы избежать этой проблемы?
Anonymous Quiz
3%
Увеличить таймауты и добавить повторные попытки отправки
84%
Реализовать идемпотентность обработки сообщений на стороне получателя
8%
Использовать синхронный REST вместо очереди
5%
Хранить все отправленные сообщения в отдельной таблице для аудита
✅ Почему вариант B — правильный:
Идемпотентность — это свойство операции, при котором многократное выполнение даёт тот же результат, что и однократное. В контексте интеграции это означает, что получатель должен уметь распознавать дубликаты и игнорировать их. Как это реализовать:
Каждое сообщение содержит уникальный идентификатор (например, message_id или order_id)
Получатель перед обработкой проверяет в своей БД, не обрабатывал ли он уже сообщение с таким ID
Если обрабатывал — просто подтверждает получение и ничего не делает
Это стандартный паттерн для очередей (RabbitMQ, Kafka) и для REST API с идемпотентными ключами.
❌ Почему другие варианты не решают проблему:
A (Увеличить таймауты и добавить retry): Это только увеличит вероятность повторных отправок при сбоях, но не устранит дубликаты. Retry нужны для надёжности, но они должны сочетаться с идемпотентностью.
C (Перейти на синхронный REST): Синхронные вызовы тоже могут дублироваться при таймаутах (клиент не получил ответ и отправил ещё раз). Проблема не решается сменой протокола.
D (Хранить все отправленные сообщения): Это полезно для аудита, но не предотвращает дублирование. Если служба доставки получит дубликат, она его обработает, даже если вы храните логи.
Совет: При проектировании интеграции всегда требуйте от команды реализации идемпотентности на стороне получателя. Это одно из золотых правил распределённых систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
4713. Партнёр требует обеспечить безопасность передачи: данные должны быть защищены от перехвата и подделки, а также необходима гарантия, что запросы приходят именно от вашей системы. Какой механизм аутентификации и шифрования выбрать?
Anonymous Quiz
3%
Basic Authentication (логин/пароль) по HTTP
5%
API-ключ в заголовке запроса без шифрования
88%
HTTPS с взаимной аутентификацией (mTLS) и клиентским сертификатом
3%
Передачу данных через общий VPN-туннель
✅ Почему mTLS — лучший выбор:
Шифрование и целостность: HTTPS (TLS) обеспечивает шифрование трафика и защиту от подделки (man-in-the-middle).
Взаимная аутентификация (mutual TLS): Обычный TLS проверяет только сертификат сервера (удостоверяет подлинность партнёра для вас). mTLS добавляет проверку клиентского сертификата — партнёр также удостоверяется, что запрос идёт именно от вашей системы.
Криптографическая надёжность: Сертификаты сложнее подделать или украсть, чем пароли или API-ключи.
Промышленный стандарт: mTLS поддерживается всеми современными HTTP-клиентами и серверами, используется в финансовом секторе, Госуслугах и т.д.
❌ Почему другие варианты хуже:
A (Basic Auth по HTTP): Во-первых, HTTP не шифрует трафик — логин и пароль передаются в открытом виде (base64, который легко декодируется). Во-вторых, Basic Auth даёт слабую аутентификацию, пароли можно подобрать или перехватить.
B (API-ключ без шифрования): API-ключ — это фактически пароль. Без шифрования он передаётся открыто и может быть украден. К тому же, API-ключ не даёт криптографической гарантии подлинности отправителя.
D (VPN): VPN создаёт зашифрованный туннель между сетями, что решает проблему шифрования. Но:
VPN сложнее настраивать и поддерживать (нужно оборудование/софт с обеих сторон)
Он не решает проблему аутентификации конкретного приложения внутри туннеля — любой сервис из вашей сети сможет отправлять запросы
Избыточно для одной интеграции
Совет: Для B2B-интеграций с высокими требованиями к безопасности (финансы, персональные данные) mTLS — стандарт. В спецификации обязательно укажите требования к сертификатам: кто выпускает, срок действия, процедура обновления.
Please open Telegram to view this post
VIEW IN TELEGRAM
4714. Вы проектируете интеграцию для обмена данными между несколькими маркетплейсами. Каждый маркетплейс имеет свой формат данных и свои API. Какую архитектуру выбрать, чтобы минимизировать связанность и упростить добавление новых маркетплейсов в будущем?
Anonymous Quiz
9%
Для каждого маркетплейса написать отдельную интеграцию "точка-точка"
4%
Создать единую базу данных, в которую маркетплейсы будут загружать свои требования
59%
Разработать адаптер, который преобразует внутренний формат магазина в форматы каждого маркетплейса
28%
Использовать ESB (Enterprise Service Bus) с единой канонической моделью данных
✅ Почему вариант C (адаптер) — хороший выбор:
Паттерн адаптер (или API gateway для интеграций) предполагает:
Внутренняя система (магазин) работает в своём внутреннем формате
Адаптер получает данные от магазина, преобразует их в формат каждого маркетплейса и отправляет через их API
При добавлении нового маркетплейса нужно написать только новый адаптер, не меняя код магазина
Это снижает связанность (магазин не зависит от форматов маркетплейсов) и упрощает расширение.
✅/ ❌ Почему вариант D (ESB с канонической моделью) — ещё лучше, но сложнее:
ESB (Enterprise Service Bus) — это более мощный, но и более сложный вариант. Вводится единая каноническая модель данных (например, универсальный формат товара, понятный внутри компании). Все системы преобразуют свои данные в каноническую модель и обратно. Это идеально для большого количества систем, но требует серьёзной инфраструктуры.
Для 3-4 маркетплейсов вариант C проще и быстрее. Для десятков — D.
❌ Почему другие варианты плохи:
A (Точка-точка): Классический спагетти-код интеграций. Каждая новая связь требует изменений и в магазине, и в адаптере. При росте числа маркетплейсов сложность растёт экспоненциально. Трудно поддерживать и тестировать.
B (Единая база данных): Предоставление доступа к своей БД внешним системам — антипаттерн. Это нарушает безопасность, инкапсуляцию, создаёт зависимость от схемы данных. Маркетплейсы не смогут работать с вашей внутренней схемой напрямую.
Совет: Для такой задачи аналитик должен:
Определить внутреннюю модель данных товара (каноническую для компании)
Для каждого маркетплейса описать правила маппинга из внутренней модели в их формат
Специфицировать адаптер как отдельный компонент, который будет выполнять это преобразование и управлять вызовами API
Учесть обработку ошибок, повторные попытки, логирование
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
4715. User story: смена пароля. Какие критерии приёмки сделают её проверяемой?
Anonymous Quiz
6%
Поле обязательно, кнопка работает, есть сообщение.
4%
Пароль безопасный, приходит уведомление.
90%
1. Длина ≥8, цифра и заглавная. 2. Приходит email. 3. Старый пароль не работает.
0%
Как в других банковских приложениях
❌ A: слишком размыто («работает», «сообщение» — какое?).
❌ B: отсылка к неопределённой «политике безопасности», не проверяемо.
❌ D: субъективно, невозможно проверить объективно.
Please open Telegram to view this post
VIEW IN TELEGRAM
4716. Логика скидок:
сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
сумма>5000 + участник =15% сумма>5000 + не участник =5% сумма≤5000 =0% Какая техника тест-дизайна лучше всего подходит?
Anonymous Quiz
12%
Эквивалентное разделение
40%
Таблица решений
11%
Попарное тестирование
37%
Анализ граничных значений
❌ A: эквивалентное разделение не учитывает комбинации условий.
❌ C: попарное тестирование избыточно для двух параметров и не даёт такой наглядности.
❌ D: анализ граничных значений полезен для чисел, но не проверяет комбинации условий.
Please open Telegram to view this post
VIEW IN TELEGRAM
4717. Тестировщик нашёл: система позволяет записаться на уже занятое время. Разработчик: «Так в ТЗ — сначала выбор, потом проверка». Ваши действия?
Anonymous Quiz
2%
Согласиться с разработчиком.
75%
Уточнить у заказчика ожидаемое поведение, при необходимости скорректировать ТЗ.
1%
Закрыть баг как «не баг».
23%
Предложить добавить валидацию на фронтенде.
❌ A: слепое следование ТЗ может привести к плохому UX.
❌ C: закрытие база без анализа игнорирует потенциальную проблему.
❌ D: техническое решение без проработки требований может не соответствовать бизнес-логике.
Please open Telegram to view this post
VIEW IN TELEGRAM
4718. Для интеграционного тестирования микросервисов нужны тестовые данные. Что сделает аналитик?
Anonymous Quiz
1%
Даст доступ к production-базе.
6%
Напишет сценарии тестирования.
92%
Подготовит документацию с примерами данных, форматами и скриптами генерации по бизнес-правилам.
1%
Попросит разработчиков написать юнит-тесты.
❌ A: доступ к production нарушает безопасность и законы о персональных данных.
❌ B: написание сценариев — задача тестировщика.
❌ D: юнит-тесты не решают проблему интеграционных данных.
Please open Telegram to view this post
VIEW IN TELEGRAM