← Назад к вопросам
Описать интеграцию четырёх систем для процесса выдачи банковской карты
1.0 Junior🔥 191 комментариев
#API и интеграции#Архитектура систем
Условие
Есть четыре системы, участвующие в последовательном исполнении заказа клиента на выдачу банковской карты:
- Форма заявки — веб-приложение для подачи заявки на карту
- Скоринг — система оценки кредитоспособности клиента
- Печать карты — система управления производством карт
- Логистика — система доставки карты клиенту
Задача: Опишите, как вы интегрируете эти системы между собой.
Требования:
- Выберите тип интеграции (синхронная/асинхронная) для каждой связи и обоснуйте выбор
- Опишите формат передаваемых данных
- Опишите обработку ошибок на каждом этапе
- Нарисуйте или опишите диаграмму последовательности (Sequence Diagram)
Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Интеграция четырёх систем для выдачи банковской карты
Обзор архитектуры
Процесс выдачи карты включает 4 последовательных этапа с различными требованиями к интеграции:
- Приём заявки (Форма заявки)
- Оценка риска (Скоринг)
- Производство (Печать карты)
- Доставка (Логистика)
1. Типы интеграции и обоснование
Форма заявки → Скоринг: Синхронная интеграция (REST API)
Обоснование:
- Требуется немедленный результат (одобрена/отклонена заявка)
- Клиент ждёт ответа на экране
- Процесс не должен быть заблокирован на долгое время
- Очень быстрое выполнение (обычно 2-5 секунд)
Реализация:
Форма заявки --[HTTP POST]-> Скоринг
<-[JSON ответ]--
Таймаут: 10 секунд
Скоринг → Печать карты: Асинхронная интеграция (Message Queue)
Обоснование:
- Печать карты — длительный процесс (часы)
- Клиент не должен ждать результат в реальном времени
- Высокая нагрузка: много заявок в день
- Необходимо гарантировать обработку (надёжность)
- Требуется отслеживание статуса
Реализация:
- Message Broker: RabbitMQ или Apache Kafka
- Guaranted delivery (персистентность)
- Retry mechanism с exponential backoff
Скоринг --[AMQP Message]-> Message Queue -> Печать карты
одобрено (персистентно) (обработка)
Печать карта → Логистика: Асинхронная интеграция (Webhook)
Обоснование:
- Печать карты уведомляет о готовности
- Логистика может начать подготовку к отправке
- Асинхронность снижает нагрузку
- Webhook позволяет системе печати инициировать отправку
Реализация:
Печать карты --[HTTP POST Webhook]-> Логистика
(когда карта готова) (начать доставку)
2. Формат передаваемых данных
2.1 Заявка на скоринг (Синхронный запрос)
{
"request_id": "uuid-12345",
"timestamp": "2025-03-23T10:30:00Z",
"client": {
"full_name": "Иван Петров",
"email": "ivan@example.com",
"phone": "+7 999 123 45 67",
"passport_series": "1234",
"passport_number": "567890",
"birth_date": "1990-05-15",
"employment": "employed",
"annual_income": 1200000,
"marital_status": "married",
"children_count": 2
},
"card_type": "premium",
"credit_limit": 500000
}
Ответ скоринга:
{
"request_id": "uuid-12345",
"decision": "approved",
"score": 850,
"credit_limit_approved": 500000,
"annual_rate": 12.5,
"processing_time_ms": 2347,
"timestamp": "2025-03-23T10:30:03Z"
}
Возможные значения decision: approved, declined, manual_review
2.2 Заказ на печать карты (Асинхронное сообщение)
{
"order_id": "order-uuid-99999",
"request_id": "uuid-12345",
"created_at": "2025-03-23T10:30:05Z",
"card_details": {
"cardholder_name": "IVAN PETROV",
"card_number_mask": "****5678",
"expiry_date": "03/28",
"card_type": "premium",
"color": "black",
"special_design": false
},
"delivery_address": {
"full_name": "Иван Петров",
"street": "ул. Тверская, д. 15, кв. 42",
"city": "Москва",
"postal_code": "121000",
"phone": "+7 999 123 45 67"
},
"priority": "standard",
"estimated_ready_date": "2025-04-02"
}
2.3 Уведомление о готовности карты (Webhook)
{
"event": "card_ready_for_shipment",
"order_id": "order-uuid-99999",
"timestamp": "2025-04-02T14:30:00Z",
"card_details": {
"cardholder_name": "IVAN PETROV",
"tracking_batch": "BATCH-2025-04-0042",
"ready_date": "2025-04-02"
},
"next_action": "prepare_shipment"
}
2.4 Инструкция доставки (Асинхронное сообщение)
{
"shipment_id": "ship-uuid-55555",
"order_id": "order-uuid-99999",
"created_at": "2025-04-02T14:35:00Z",
"recipient": {
"full_name": "Иван Петров",
"phone": "+7 999 123 45 67",
"email": "ivan@example.com",
"address": "ул. Тверская, д. 15, кв. 42, 121000, Москва"
},
"carrier": "DPD",
"tracking_batch": "BATCH-2025-04-0042",
"estimated_delivery": "2025-04-05",
"require_signature": true,
"insurance_amount": 50000
}
3. Обработка ошибок на каждом этапе
3.1 Ошибки при скоринге
| Ошибка | Код | Обработка | Действие |
|---|---|---|---|
| Некорректные данные | 400 | Валидация на стороне формы | Вернуть форму пользователю с указанием ошибок |
| Сервис недоступен | 503 | Retry 3 раза с задержкой 2, 5, 10 сек | Показать "Временная проблема, попробуйте позже" |
| Таймаут (>10 сек) | 504 | Повторить запрос один раз | Показать "Проверка идёт, подождите" |
| Внутренняя ошибка скоринга | 500 | Логировать, создать incident | Вернуть пользователю "Ошибка системы, обратитесь в поддержку" |
Стратегия: Все ошибки скоринга отправляют пользователя на экран "Проверка не прошла" с опцией повторить.
3.2 Ошибки при отправке заказа на печать
| Ошибка | Обработка | Действие |
|---|---|---|
| Сообщение не доставлено в очередь | Retry механизм (exponential backoff) | Повторить 5 раз с задержкой 1, 2, 5, 10, 30 мин |
| Сообщение потеряно | Dead Letter Queue (DLQ) | Автоматическое создание задачи поддержке |
| Некорректный адрес доставки | Валидация перед отправкой в очередь | Вернуть заявку в статус "Требуется коррекция адреса" |
| Данные некорректны | Ошибка при десериализации | Отправить в DLQ, создать alert |
Стратегия: Гарантированная доставка через Message Queue. Если сообщение в очереди неудачно обработано 5 раз → DLQ → Manual review.
3.3 Ошибки при получении webhook от печати
| Ошибка | Обработка | Действие |
|---|---|---|
| Webhook недоставлен | Retry webhook 3 раза (экспоненциальный backoff) | Параллельно: polling система печати каждые 30 минут |
| Webhook содержит некорректные данные | Валидация схемы JSON | Логирование, уведомление печати о ошибке |
| Логистика недоступна при получении webhook | Queue webhook сообщение | Обработать асинхронно, когда логистика вернётся |
Стратегия: Обеспечить идемпотентность. Webhook может прийти несколько раз, система должна обработать это корректно (использовать order_id как ключ).
3.4 Ошибки при отправке в логистику
| Ошибка | Обработка | Действие |
|---|---|---|
| Логистика занята | Message Queue буферизирует сообщения | Автоматическая обработка при освобождении |
| Некорректные адресные данные | Валидация перед отправкой | Направить на ручное одобрение адреса |
| Потеря сообщения | Полинг состояния заказа каждый час | Повторная отправка если статус не обновлён |
4. Диаграмма последовательности (Sequence Diagram)
Форма Скоринг Queue Печать Webhook Логистика
| | | | | |
|--[1]-------->| | | | |
| Заявка | | | | |
| | | | | |
|<--[2]--------| | | | |
| Результат | | | | |
| (3 сек) | | | | |
| | | | | |
|--[3]----------------------->| | | |
| Заказ на печать (async) | | | |
| | | | | |
| | |--[4]------->| | |
| | | Сообщение | | |
| | | из очереди | | |
| | | | | |
| | | |--[5]-ACK->| |
| | | | Получен | |
| | |<--[6]-------| | |
| | | Удалить из | | |
| | | очереди | | |
| | | | | |
| | (...) Печать идёт 3-5 дней | |
| | | | | |
| | | |--[7]POST Webhook------->|
| | | | Карта готова (async) |
| | | | | |
| | | |<--[8]----| 200 OK |
| | | | Ответ | |
| | | | | |
| | | (...) |--[9]--------|
| | | | Заказ на | Доставить |
| | | | логистику | |
| | | | | |--[10]----->|
| | | | | | из Queue |
| | | | | | |
| | | | | |<--[11]-----|
| | | | | | ACK |
| | | | | | |
| | | | | | (доставка)
| | | | | | 2-5 дней
| | | | | | |
| | | | | |--[12]------|
| | | | | | Карта |
| | | | | | доставлена
| | | | | | |
Легенда:
[1] HTTP POST - синхронный запрос
[2] HTTP 200 - синхронный ответ
[3] AMQP Message - асинхронное сообщение в очередь
[4] Message из очереди
[5-6] ACK в очередь
[7] HTTP POST Webhook
[8] HTTP 200 ответ
[9-10] Второе асинхронное сообщение
[11] ACK
[12] Событие доставки
5. Архитектурные компоненты
Форма заявки (веб-приложение)
- REST клиент для синхронного вызова скоринга
- Обработчик ошибок с retry логикой
- Валидация данных перед отправкой
- Интеграция с CRM/системой управления заявками
Скоринг (мулти-сервис)
- REST API с таймаутом 10 сек
- Логирование всех запросов и ответов
- Кэширование результатов (если возможно)
- Отправка одобренных заявок в Message Queue
Message Queue (RabbitMQ/Kafka)
- Dead Letter Queue для неудачных сообщений
- Персистентность на диске
- Гарантированная доставка
- Consumer group для масштабируемости
Печать карты
- Consumer из Message Queue
- REST endpoint для Webhook о готовности
- Отправка webhook в систему логистики
- Отслеживание статуса заказов
Логистика
- Webhook consumer для получения заказов
- Собственная Message Queue для очередности
- Интеграция с курьерскими сервисами
- Отправка уведомлений клиенту о доставке
6. Надёжность и масштабируемость
Идемпотентность: Все операции должны быть идемпотентными (безопасное повторное выполнение)
- Используйте order_id как уникальный ключ
- Проверяйте дубликаты перед обработкой
Мониторинг:
- Отслеживать время обработки на каждом этапе
- Алерты при задержках >2 часов
- Dashboard с метриками: успешно/отклонено/в обработке
Масштабируемость:
- Горизонтальное масштабирование через Message Queue consumers
- Форма заявки - статeless, можно масштабировать фронт
- Каждый микросервис независимо масштабируется по нагрузке
Отказоустойчивость:
- Dead Letter Queue для анализа ошибок
- Автоматические алерты при критических ошибках
- Возможность manual override в системе админ-панели