4801. При интеграции с платёжным шлюзом поступление callback-ов иногда приводит к дублированию платежей (одна и та же транзакция обрабатывается дважды). Какое требование аналитик должен добавить в спецификацию интеграции?
Anonymous Quiz
2%
Увеличить таймаут ожидания ответа от шлюза
95%
Обработка должна быть идемпотентной с использованием уникального ID транзакции
3%
Отключить повторные callback-и на стороне шлюза
0%
Сохранять все входящие запросы в отдельную таблицу для ручного разбора
Платёжные системы часто работают по семантике at-least-once (как минимум один раз). Это означает, что при сомнении (таймаут, неполучение подтверждения, перезапуск) шлюз может отправить callback повторно. Сетевые сбои, перезагрузки серверов — обычная причина дублей. Если ваша система списывает деньги при каждом вызове, клиент заплатит дважды.
2. Идемпотентность — единственное решение
Идемпотентная операция при повторном выполнении с теми же входными данными не меняет состояние системы. В данном случае: обработав первый callback, вы списываете деньги и запоминаете уникальный ID транзакции (например, payment_id). При повторном callback вы проверяете: если payment_id уже обработан — просто возвращаете успех, не списывая повторно. Технически это делается через хранение ID в Redis (с TTL) или в БД с уникальным индексом.
3. Почему не подходят другие варианты?
A (увеличить таймаут) — не влияет на дубликаты, таймаут отвечает за время ожидания ответа от вашего сервера шлюзом, но шлюз может дублировать и без таймаута.
C (отключить повторные callback на стороне шлюза) — невозможно, это внутренняя логика шлюза. Даже если бы можно было, вы снизите надёжность: при временном сбое уведомление потеряется навсегда.
D (ручной разбор) — не масштабируется, при тысячах платежей в день ручная проверка невозможна, бизнес не успеет.
4. Реальный кейс
Интернет-магазин подключил платёжный шлюз. В первые часы у нескольких клиентов списались деньги дважды. Анализ показал, что шлюз отправлял дубликат при задержке ответа магазина более 2 секунд. Внедрение идемпотентности на основе transaction_id позволило автоматически отсекать дубликаты без потери надёжности.
5. Что должен зафиксировать аналитик в требованиях
«Обработка callback-ов должна быть идемпотентной. Для этого использовать уникальный идентификатор платежа, предоставляемый шлюзом (поле payment_id), и хранить обработанные ID в Redis или БД с временем жизни не менее 24 часов».
«При повторном получении callback-а с уже обработанным ID система должна возвращать HTTP 200 OK без повторного выполнения бизнес-логики».
«Для защиты от гонок использовать блокировки или атомарные операции (например, SET NX в Redis)».
Вывод: Идемпотентность — обязательное требование для любой интеграции, где внешняя система может повторять запросы (а это почти все платёжные, SMS, email-сервисы). Без неё дублирование неизбежно приведёт к финансовым потерям и недовольству клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
4802. При моделировании процесса выдачи кредита две независимые проверки должны выполняться одновременно и не мешать друг другу. Процесс продолжается только после завершения обеих проверок. Какой элемент BPMN следует использовать?
Anonymous Quiz
0%
Исключающий шлюз (XOR)
97%
AND-шлюз (параллельный) с разветвлением (fork) и слиянием (join)
2%
Включающий шлюз (OR)
1%
Событийный шлюз (Event-based Gateway)
Две проверки не зависят друг от друга: одну можно выполнять в кредитном бюро, другую в скоринговой системе. Нет смысла делать их последовательно — это удвоит время ожидания. Нужно запустить их параллельно и продолжить процесс только после того, как обе завершатся.
2. Как работает AND-шлюз
Fork (разветвление): шлюз с одним входом и двумя выходами. Поток разделяется на две параллельные ветки. Обе выполняются одновременно.
Join (слияние): шлюз с двумя входами и одним выходом. Он пропускает поток дальше только после того, как все входящие ветки завершились.
Соединяя fork и join, вы получаете параллельное выполнение с синхронизацией.
3. Почему не подходят другие шлюзы
XOR (исключающий) — активирует только один путь из нескольких. Если поставить XOR, будет выполнена только одна проверка, вторая не запустится. Не подходит.
OR (включающий) — может активировать один или несколько путей. Но при слиянии OR продолжает работу после завершения первой активированной ветки, не дожидаясь остальных. Это не гарантирует выполнения обеих проверок.
Событийный шлюз — выбирает путь на основе наступления события (таймер, сообщение). Для параллельного выполнения не используется.
4. Реальный кейс
В банке процесс выдачи кредита изначально был последовательным: сначала скоринг (1 минута), потом кредитная история (1 минута). Заявка обрабатывалась 2 минуты. Аналитик перерисовал процесс с AND-шлюзом: проверки запускаются параллельно, общее время сократилось до 1 минуты. Клиенты стали получать решение в два раза быстрее.
5. Дополнительные детали для аналитика
Дорожки (swimlanes) помогают показать, кто за какую проверку отвечает (скоринг — отдел рисков, кредитная история — бюро).
Таймеры можно прикрепить к каждой ветке: если одна проверка зависла, через 30 секунд отправить уведомление администратору.
Исключения: если одна из проверок падает с ошибкой, то join не сработает. Нужно добавить шлюз для обработки ошибок (например, если скоринг недоступен, вернуть отказ).
Вывод: AND-шлюз (fork/join) — ключевой элемент BPMN для параллельного выполнения независимых задач и синхронизации. Его правильное применение сокращает время процессов и повышает эффективность.
Please open Telegram to view this post
VIEW IN TELEGRAM
Science & Education 🌍🔬
Папка для тех, кто погружен в мир научных исследований, современных образовательных технологий и задумывается о международной карьере.
Мы отобрали каналы, которые реально помогают в обучении и работе: от свежих научных публикаций и EdTech-трендов, советов по управлению сложными интеллектуальными проектами до актуальных подборок стипендий и грантов по поступлению в топовые вузы мира🔥
👉 ОТКРЫТЬ ДОСТУП
Папка для тех, кто погружен в мир научных исследований, современных образовательных технологий и задумывается о международной карьере.
Мы отобрали каналы, которые реально помогают в обучении и работе: от свежих научных публикаций и EdTech-трендов, советов по управлению сложными интеллектуальными проектами до актуальных подборок стипендий и грантов по поступлению в топовые вузы мира🔥
👉 ОТКРЫТЬ ДОСТУП
4803. На приёмке выяснилось, что для некоторых товаров НДС 10%, а для экспортных — 0%. Претензия заказчика: «Я же просил автоматически — значит, сама должна понимать ставку». Что упустил аналитик?
Anonymous Quiz
1%
Не проверил, что разработчик знаком с налоговым кодексом
93%
Не декомпозировал требование на явные бизнес-правила (категории товаров, ставки, исключения)
2%
Не добавил ручной ввод ставки для сложных случаев
5%
Не согласовал требование с бухгалтерией до разработки
Если товар в категории «Продовольствие», то НДС 10%.
Если страна назначения не РФ, то НДС 0%.
Для остальных — 20%.
Без такой детализации разработчик принимает решение по умолчанию, которое почти наверняка окажется неверным. Это реальная проблема на проектах, где бизнес-правила сложны. Аналитик должен превращать «автоматически» в алгоритм.
Please open Telegram to view this post
VIEW IN TELEGRAM
В начале мая сразу несколько новостей показали, куда двигается рынок: спрос на готовые ИТ-бизнесы вырос на 30%, а компании всё активнее пересобирают процессы вокруг ИИ и инфраструктуры. Плюс бизнесу снова приходится быстро адаптироваться к новым правилам и ограничениям — без хороших ориентиров это уже не про рост, а про выживание.
Чтобы не тратить время на случайные каналы и шум, собрали папку с экспертами по IT и бизнесу. Внутри — люди, которые разбирают рынок по делу: без лишней теории, с практикой, кейсами и нормальной аналитикой.
Это подборка для тех, кто хочет быстрее понимать, что происходит в рынке, и принимать решения без лишней суеты.
Сохранить папку себе 📨
Чтобы не тратить время на случайные каналы и шум, собрали папку с экспертами по IT и бизнесу. Внутри — люди, которые разбирают рынок по делу: без лишней теории, с практикой, кейсами и нормальной аналитикой.
Это подборка для тех, кто хочет быстрее понимать, что происходит в рынке, и принимать решения без лишней суеты.
Сохранить папку себе 📨
4804. Тестировщики проверяли биометрию — работает. Оказывается, баг проявляется только если пользователь меняет язык приложения на английский. Какой вид тестирования должен бы
Anonymous Quiz
0%
Нагрузочное тестирование
72%
Тестирование комбинаций (парное тестирование, decision table)
1%
Тестирование безопасности
28%
Юзабилити-тестирование
Please open Telegram to view this post
VIEW IN TELEGRAM
4805. Запрос SELECT * FROM clients WHERE inn = ? выполняется 3 секунды, хотя на поле inn есть индекс. Индекс не используется. Почему это влияет на производительность?
Anonymous Quiz
50%
База данных не может использовать индекс из-за несовместимости типов (сравнение числа со строкой)
5%
Индекс повреждён из-за неявного преобразования
35%
Необходимо использовать параметризованный запрос с приведением типов
10%
Проблема в объёме данных, нужно партиционирование
🤔3
Please open Telegram to view this post
VIEW IN TELEGRAM
4805. В логистической компании Kafka используется для передачи событий о перемещении грузов. Один из консьюмеров (система учёта) периодически падает из-за ошибки в формате данных.
Какое архитектурное требование аналитик должен был добавить?
Какое архитектурное требование аналитик должен был добавить?
Anonymous Quiz
5%
Увеличить retention сообщений до 30 дней
78%
Настроить Dead Letter Queue для сообщений
6%
Добавить мониторинг лага потребителя
12%
Переключить консьюмера в режим at-most-once
Please open Telegram to view this post
VIEW IN TELEGRAM