Описание процесса

Ваша компания разрабатывает интернет-магазин. Пользователи вашего магазина могут:

• Создавать заказы
• Оплачивать заказы

Для оплаты заказа ваш магазин использует внешнего провайдера оплаты. Он предоставляет вам N аккаунтов. Вы обращаетесь к провайдеру по протоколу HTTP, передавая данные аккаунта и детали оплаты. Описание вызова провайдера оплаты

Первоначальная интеграция оплаты уже произведена - все настроено и ваш сервис умеет делать HTTP запрос к одному из аккаунтов. Вы можете увидеть необходимый код в пакете ru.quipy.payments , интерфейсах PaymentService , PaymentExternalSystemAdapter и их реализациях

Вам необходимо оптимизировать процесс взаимодействия с провайдером при большом количестве запросов, учитывая особенности аккаунтов и возможное поведение системы провайдера.

Термины предметной области

Клиентские приложения / Клиенты - сервис или набор сервисов, которые делают покупки в онлайн-магазине, инициируют процесс оплаты заказа.

Онлайн-магазин / Интернет-магазин / Магазин - сервис, который осуществляет управление логикой создания заказов и оплаты через внешнего провайдера. Сервис, который вам предстоит дорабатывать.

Провайдер оплаты - внешний сервис, через который осуществляется оплата заказа

• Не находится под управлением вашей компании. Например, банковский шлюз / шлюз платежной системы.
• Берет плату за использование. Размер платы определен тарифом аккаунта. Каждое использование (каждый входящий HTTP вызов) стоит N условных единиц.

Аккаунт провайдера оплаты - логическая сущность, которая позволяет идентифицировать пользователя и его тариф. Стоит относиться к каждому аккаунту как к отдельному внешнему сервису со своим поведением.

• Аккаунт имеет уникальное наименование и ассоциированный с ним токен. Эти данные обязательно передавать провайдеру при выполнении вызова (см. Описание вызова провайдера оплаты )
• Каждый аккаунт предоставляет определенное качество и объем сервиса (SLA)
  • Позволяет выполнять не более N запросов в единицу времени
  • Позволяет выполнять не более M одновременных (параллельных) запросов
  • Отвечает за время P секунд в среднем
  • Возвращает результат - true/false в зависимости от того, успешно ли прошла оплата. В случае, если вернулось false оплату можно попробовать выполнить повторно

Кейсы

Каждое задание-кейс предоставляет вам следующие входные данные / контекст:

1. Один или более аккаунтов провайдера оплаты
2. Оплаты должна завершиться менее чем за T секунд, тогда пользователь магазина считает ее успешной
3. Параметры для запуска тестирования
   • Количество тестов в секунду (test rate per second ≠ request per second)
   • Общее количество заказов в рамках теста
   • Параметры аккаунтов (SLA)
   • Более расширенные параментры тестирования будут представлены по ходу курса

Цели

Извлечь максимальную финансовую выгоду для онлайн-магазина, оплачивая максимальное количество заказов.