Как правильно разработать легкомасштабируемую платёжную систему?
Задача: необходимо спроектировать платежную систему по аналогии QIWI, подобрать необходимый стэк технологий, правильно разбить систему на компоненты. Критична стабильность и устойчивость к нагрузкам. Так же в планах реализация своего api для клиентов.
Как я я понимаю с денежными транзакциями необходимо работать следующим образом: клиент оставляет заявку на проведение денежной операции (внутренний перевод с баланса на баланс, либо пополнение из вне), далее заявка отправляется в обработчик заявок который выполняет данную операцию (производит перевод, либо выставляет счёт, проверяет статус оплаты и затем увеличивает баланс).
Отсюда можно разбить систему на следующие модули:
- веб интерфейс (со стороны пользователя личный кабинет, разная вспомогающая информация и т.д со стороны операторов отслеживание ошибок, просмотр логов операций и т.д);
- очередь заявок (грубо говоря список заказанных транзакций. откуда кому куда и текущий статус: выполнено, ожидание, готово):
- модуль управления с заявками (взять список не выполненных, выставить счет на в определенную платежную систему, проверить у нее же на оплаченность, переключить статус, удалить заявку);
- модуль работы со сторонними платежными системами (получить инструкцию собрать json или xml => разобрать полученное вернуть результат);
Изначально задумка реализовать систему на Symfony т.е полностью на php в качестве бд использовать postgres, но отсюда всплывает несколько вопросов.
При малых нагрузках (100 - 1000 заявок на обработку), вешаеться php скрипт на крон и всё будет работать довольно шустро, но как оптимизировать если заявок будет скажем 500 000. Можно собрать обработчик на java и запустить в многопоточном режиме. Но тогда получается нужно продублировать модуль управления с заявками и работу с модулем работы со сторонними платежными системами.
Так как для веб интерфейса тоже необходимо создать заявку посмотреть результат (баланс).
Как вариант была идея реализовать бэкэнд как RESTfull api (на java) а веб интерфейс как клиент.
Понимаю тема довольно объемная. Поэтому буду раз как ответу в общих чертах так и ссылкам на статьи или книги которые помогут лучше разобраться в данном вопросе.
1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq
2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.
По поводу синхронности/асинхронности - это вполне можно уместить в одном апи. Какие методы делать синхронными, какие нет - целиком зависит от вашей бизнес логики.
На мой взгляд получение баланса например вполне можно сделать синхронным.
3. С точки зрения быстродействия - Вы достаточно быстро упретесь в базу. Соответственно надо сразу думать о шардировании данных, о том как система будет себя вести в случае выхода из строя одной из задействованных в транзакции нод итд.
4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.
5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.
6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)
PS Я хочу верить что Ваш вопрос - это задачка для саморазвития. Иначе я не представляю себе что это за система платежная, которую делает один человек, спрашивающий совета как делать такие штуки (опять же не в обиду Вам ) :)
когда заявок много делается куча воркеров и распределенная очередь куда складываются заявки и откуда воркеры берут их на исполнение
реализаций очереди куча
Простой
Простой
