Как правильно разработать легкомасштабируемую платёжную систему?

Задача: необходимо спроектировать платежную систему по аналогии QIWI, подобрать необходимый стэк технологий, правильно разбить систему на компоненты. Критична стабильность и устойчивость к нагрузкам. Так же в планах реализация своего api для клиентов.

Как я я понимаю с денежными транзакциями необходимо работать следующим образом: клиент оставляет заявку на проведение денежной операции (внутренний перевод с баланса на баланс, либо пополнение из вне), далее заявка отправляется в обработчик заявок который выполняет данную операцию (производит перевод, либо выставляет счёт, проверяет статус оплаты и затем увеличивает баланс).

Отсюда можно разбить систему на следующие модули:
- веб интерфейс (со стороны пользователя личный кабинет, разная вспомогающая информация и т.д со стороны операторов отслеживание ошибок, просмотр логов операций и т.д);
- очередь заявок (грубо говоря список заказанных транзакций. откуда кому куда и текущий статус: выполнено, ожидание, готово):
- модуль управления с заявками (взять список не выполненных, выставить счет на в определенную платежную систему, проверить у нее же на оплаченность, переключить статус, удалить заявку);
- модуль работы со сторонними платежными системами (получить инструкцию собрать json или xml => разобрать полученное вернуть результат);

Изначально задумка реализовать систему на Symfony т.е полностью на php в качестве бд использовать postgres, но отсюда всплывает несколько вопросов.
При малых нагрузках (100 - 1000 заявок на обработку), вешаеться php скрипт на крон и всё будет работать довольно шустро, но как оптимизировать если заявок будет скажем 500 000. Можно собрать обработчик на java и запустить в многопоточном режиме. Но тогда получается нужно продублировать модуль управления с заявками и работу с модулем работы со сторонними платежными системами.
Так как для веб интерфейса тоже необходимо создать заявку посмотреть результат (баланс).

Как вариант была идея реализовать бэкэнд как RESTfull api (на java) а веб интерфейс как клиент.

Понимаю тема довольно объемная. Поэтому буду раз как ответу в общих чертах так и ссылкам на статьи или книги которые помогут лучше разобраться в данном вопросе.
  • Вопрос задан
  • 2622 просмотра
Решения вопроса 1
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги
1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq

2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.

По поводу синхронности/асинхронности - это вполне можно уместить в одном апи. Какие методы делать синхронными, какие нет - целиком зависит от вашей бизнес логики.
На мой взгляд получение баланса например вполне можно сделать синхронным.

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

4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.

5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.

6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)

PS Я хочу верить что Ваш вопрос - это задачка для саморазвития. Иначе я не представляю себе что это за система платежная, которую делает один человек, спрашивающий совета как делать такие штуки (опять же не в обиду Вам ) :)
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 3
FanatPHP
@FanatPHP
Чебуратор тега РНР
1. Найти финансирование, от $10M
2.Нанять команду профессионалов.

Да, а школу сначала все-таки надо будет закончить.
Ответ написан
Комментировать
opium
@opium
Просто люблю качественно работать
когда заявок много делается куча воркеров и распределенная очередь куда складываются заявки и откуда воркеры берут их на исполнение
реализаций очереди куча
Ответ написан
Комментировать
@salex772
Вам лучше подойдет решения на JVM типа Scala + Akka - так и работает PayPal.
Я имею опыт разработки финансовой системы с разными валютами и тд
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы