Системная интеграция — удалённая работа в Москве

Автоматизировать бизнес. Сфера деятельности: Финансы. # Разработка высокоскоростной серверной API-интеграции с банком Ищем **сильного backend-разработчика / специалиста по высокопроизводительным API-интеграциям** для разработки и оптимизации серверного решения по массовой передаче заявок через API банка. У нас есть: * действующий партнерский доступ к API; * подробная документация API; * реальные данные для отправки; * существующий процесс передачи заявок; * несколько партнерских аккаунтов; * возможность предоставить документацию и тестовые данные исполнителю. **Главный критерий проекта — скорость отправки заявок.** Заявки передаются через API отдельными запросами. Необходимо построить серверное решение, которое сможет максимально быстро передавать большой массив заявок, используя допустимую параллельность и соблюдая технические ограничения API банка. Для нас особенно критична скорость непосредственно после **00:00:00**, так как в это время начинается массовая отправка заявок. ## Основная задача Необходимо разработать систему, в которой все тяжелые операции по возможности выполняются **до наступления 00:00**. До начала отправки должны быть заранее выполнены: * получение исходных данных; * проверка обязательных полей; * валидация данных; * нормализация телефонных номеров; * проверка ИНН, КПП, ОГРН и других параметров; * определение необходимых кодов и справочников; * преобразование исходных данных; * формирование JSON; * подготовка финальной очереди заявок. К моменту запуска массив должен быть полностью готов к отправке. После наступления заданного времени сервер должен практически сразу начать передачу запросов в API. ## 1. Максимально быстрая отправка заявок Это главная часть проекта. Необходимо изучить документацию API банка и определить оптимальную архитектуру передачи большого количества отдельных запросов. Рассматриваем использование: * asynchronous I/O; * connection pooling; * HTTP keep-alive; * нескольких workers; * очередей; * эффективной JSON-сериализации; * предварительной подготовки payload; * оптимизации DNS / TLS / network latency; * других технических способов уменьшения времени отправки. Количество параллельных запросов нельзя выбирать произвольно. Разработчик должен: 1. изучить документацию API; 2. определить технические ограничения метода отправки заявок; 3. определить ограничения партнерских аккаунтов; 4. провести допустимые тесты производительности; 5. определить оптимальный уровень concurrency; 6. определить максимально достижимый реальный RPS; 7. настроить систему так, чтобы максимальная скорость не приводила к росту количества ошибок. Нам нужен не просто разработчик, который поставит большое количество потоков, а специалист, который сможет технически определить **оптимальную архитектуру массовой отправки HTTP-запросов**. ## 2. Работа с несколькими партнерскими аккаунтами Система должна поддерживать работу сразу с несколькими нашими партнерскими аккаунтами/API-ключами. Для каждого аккаунта необходимо отдельно учитывать: * API-ключ; * авторизацию; * очередь заявок; * ограничения; * статистику; * ошибки; * результаты отправки. Необходимо предусмотреть удобное добавление новых партнерских аккаунтов без существенной переработки системы. Если правила API позволяют одновременную работу нескольких наших партнерских аккаунтов, система должна эффективно использовать эту возможность. При этом архитектура должна соблюдать ограничения API и условия партнерской работы банка. ## 3. Предварительная подготовка данных Все операции, которые можно выполнить заранее, должны выполняться **до начала массовой отправки**. В частности: * проверка структуры данных; * проверка обязательных полей; * приведение телефонов к необходимому формату; * проверка ИНН; * проверка КПП; * проверка ОГРН; * подготовка cityCode; * подготовка кодов продуктов; * получение и локальное хранение необходимых справочников; * формирование готовых JSON payload; * подготовка очереди. Цель — чтобы непосредственно после 00:00 сервер занимался практически только отправкой заранее подготовленных HTTP-запросов. Необходимо максимально убрать из критического участка: * тяжелые вычисления; * обращения к базе данных; * преобразование данных; * получение справочников; * лишние сетевые запросы. ## 4. Точный запуск около 00:00:00 Необходимо обеспечить максимально точный старт массовой отправки. Предусмотреть: * синхронизацию системного времени сервера; * NTP; * постоянно работающий процесс; * заранее сформированную очередь; * отсутствие запуска тяжелой подготовки непосредственно в 00:00; * минимальный scheduler jitter; * готовность сетевых компонентов к моменту запуска. Для нас важен не просто запуск программы по расписанию. Нас интересует минимальное время: **от 00:00:00 до фактической отправки первого запроса в API банка.** И далее — максимально быстрое прохождение всей очереди. ## 5. Надежность и обработка ошибок Высокая скорость не должна приводить к потере заявок или бесконтрольному появлению дублей. Необходимо реализовать грамотную обработку: * HTTP 400; * HTTP 401; * HTTP 403; * HTTP 500; * HTTP 503; * timeout; * connection reset; * временной недоступности API; * невалидных данных; * технических дублей; * ограничений по количеству заявок. Особенно важна ситуация: **запрос отправлен ? соединение оборвалось / произошел timeout ? неизвестно, была ли заявка фактически принята банком.** В такой ситуации нельзя просто бесконтрольно повторять POST-запрос. Необходимо разработать безопасную retry-логику, которая минимизирует риск: * потери заявки; * повторного создания заявки; * ненужной задержки всей очереди. Ошибка одной заявки не должна блокировать отправку остальных заявок. ## 6. Сохранение результата каждой отправки При успешном создании заявки API возвращает уникальный идентификатор заявки. Этот ID необходимо обязательно сохранять. Нужно хранить связь: `наша запись ? партнерский аккаунт ? время начала запроса ? время ответа ? HTTP-код ? ID заявки банка ? результат` Это необходимо для: * контроля фактической доставки; * последующей проверки; * исключения дублей; * разбора ошибок; * оценки производительности; * сравнения результатов разных партнерских аккаунтов. ## 7. Логирование Необходимо подробное техническое логирование. Для каждого запроса желательно сохранять: * внутренний ID записи; * партнерский аккаунт; * время постановки в очередь; * время начала отправки; * время получения ответа; * latency; * HTTP status; * результат; * ID заявки; * текст/код ошибки; * количество повторных попыток. При этом логирование само по себе не должно становиться узким местом и снижать скорость массовой отправки. ## 8. Мониторинг производительности Необходимо реализовать понятную статистику по каждому запуску. Хотим видеть: * общее количество заявок; * время запуска процесса; * время первого отправленного запроса; * время первого успешного ответа; * количество отправленных заявок по секундам; * RPS; * concurrency; * среднюю latency; * p50 latency; * p95 latency; * p99 latency; * количество успешных запросов; * количество ошибок; * количество retry; * время завершения всей партии. Отдельно должна быть статистика по каждому партнерскому аккаунту. Например: **Размер партии:** 10 000 заявок **Запуск:** 00:00:00.000 **Первый запрос:** 00:00:00.030 **Первый успешный ответ:** 00:00:00.120 **100 заявок принято:** 00:00:XX **1 000 заявок принято:** 00:00:XX **5 000 заявок принято:** 00:00:XX **10 000 заявок обработано:** 00:00:XX **Средний RPS:** XXX **p50:** XX ms **p95:** XXX ms **p99:** XXX ms **Ошибки:** XX Нам важно иметь возможность объективно сравнить существующее решение с новым. ## 9. Тестирование производительности После разработки необходимо провести тесты с разным уровнем параллельности. Например: * небольшой уровень concurrency; * средний; * повышенный; * максимально допустимый API. Конкретные значения необходимо определить после изучения документации и поведения API. Задача — найти точку, при которой увеличение параллельности перестает давать прирост полезной производительности либо начинает приводить к: * росту latency; * увеличению количества ошибок; * timeout; * HTTP 500/503; * ограничениям со стороны API; * падению количества успешно созданных заявок в секунду. Именно оптимальный режим необходимо использовать в production. ## 10. Возможность настройки без изменения кода Желательно вынести основные параметры в конфигурацию: * время запуска; * количество workers; * concurrency; * timeout; * параметры retry; * количество партнерских аккаунтов; * распределение заявок между аккаунтами; * пути к исходным данным; * параметры логирования. Это позволит дальше оптимизировать систему без постоянной переработки исходного кода. ## Что должно получиться на выходе Нам необходимо получить полноценное серверное решение: 1. Высокоскоростной модуль отправки заявок. 2. Предварительную подготовку данных. 3. Работу с несколькими партнерскими аккаунтами. 4. Очередь заявок. 5. Точный планировщик запуска. 6. Управление concurrency. 7. Надежную retry-механику. 8. Защиту от повторной отправки. 9. Сохранение ID созданных заявок. 10. Подробное логирование. 11. Метрики производительности. 12. Возможность настройки параметров без изменения кода. 13. Docker / удобное развертывание. 14. Исходный код проекта. 15. Инструкцию по установке и эксплуатации. 16. Помощь при первоначальном запуске и тестировании. ## Кто нам нужен Ищем человека с реальным опытом разработки **высокопроизводительных backend/API-систем**. Нужен опыт в: * Python / Go / Java / Node.js или другом подходящем backend-стеке; * REST API; * asynchronous programming; * HTTP connection pooling; * keep-alive; * concurrency; * multithreading / multiprocessing; * очередях; * Docker; * Linux; * PostgreSQL / Redis при необходимости; * профилировании; * нагрузочном тестировании; * оптимизации network latency; * обработке большого количества HTTP-запросов. Большим плюсом будет опыт: * банковских API; * fintech; * платежных систем; * рекламных API; * биржевых API; * высоконагруженных интеграций; * систем, где критична скорость обработки и отправки запросов. ## Важно **Нас не интересует обычная последовательная API-интеграция:** `взяли запись ? отправили запрос ? дождались ответа ? взяли следующую запись`. Основная задача проекта — определить и реализовать архитектуру, которая позволит **максимально быстро передавать большой объем заявок в API банка**, сохраняя надежность и соблюдая технические ограничения API. ## Что написать в отклике Просьба не писать просто «готов выполнить». Ответьте, пожалуйста, на следующие вопросы: 1. Был ли у вас опыт массовой параллельной отправки HTTP/API-запросов? 2. С какими объемами данных вы работали? 3. Какой максимальный реальный RPS был в ваших проектах? 4. Какой стек предложили бы для нашей задачи и почему? 5. Как будете определять оптимальный уровень concurrency? 6. Как организуете connection pooling и keep-alive? 7. Как будете обрабатывать timeout, если неизвестно, была ли заявка фактически создана? 8. Как защититесь от двойной отправки при retry? 9. Как будете измерять реальную производительность? 10. Как будете организовывать работу нескольких API-аккаунтов? 11. Есть ли опыт проектов, где критична скорость первых запросов после определенного времени? После первичного отбора предоставим **документацию API банка** для более предметной оценки архитектуры, сроков и стоимости. **Стоимость обсуждается. Приоритет — подтвержденный опыт высокопроизводительных API-интеграций и техническое качество решения, а не минимальная цена.**.