Python как ядро ​​социального финтех-сервиса

Python как ядро ​​социального финтех-сервиса

12 апреля 2023 г.

Мои размышления о программном обеспечении Python.

Python — это программное обеспечение для многих нишевых приложений, особенно в области науки о данных и машинного обучения. Python зарекомендовал себя как достаточное программное обеспечение для создания веб-решений с многочисленными продуктами и услугами, использующими Python. Однако игра Python в Интернете иногда все еще вращается вокруг науки о данных и машинного обучения. Это полуправда, и из моего опыта создания программного обеспечения на Python, которое не вращается вокруг этих ниш, я не видел много примеров.

Может быть, я недостаточно усердно ищу, но некоторые компании, которые, кажется, безумно используют Python, включают Instagram, Reddit и Google. В моей экосистеме (Нигерийская техосфера) я склонен полагать, что менее интересные проблемы зарезервированы для Python как такового. Я знаю только одну крупную финтех-компанию, которая использует Python в качестве основной инфраструктуры для своего бэкэнда. Из моего обсуждения с другими инженерами, которые работали с некоторыми международными банками, такими как JP Morgan Chase, они сообщили мне, что Python использовался для создания финансовых систем. С тех пор я с нетерпением жду возможности заняться чем-нибудь, связанным с финансовыми технологиями.

Недавно потенциальный работодатель дал мне задание заняться чем-то в области социального финтеха. Ниже представлена ​​информация о задаче.

The task detail.

Python как ядро ​​финансовых технологий

Имея опыт создания решений с использованием Python и FastAPI, я решил, что это подходящее место для изучения Python и FastAPI для финтеха, так как я встречался с несколькими должностями в финтех-компаниях или компаниях, занимающихся финтехом и использующих FastAPI. Эти компании доказали возможности Python.

Мое решение для приведенной выше задачи исследовало игру социальных и финансовых технологий, в этой записи я буду показывать фрагменты кода и объяснять мыслительные процессы, а не обязательно учить, как создавать финтех-продукт.

Финбанкер

Это название я придумал для этого продукта. Ниже представлена ​​структура того, как выглядит приложение.

structure of the application in terms of modules.

Точка входа приложения — src/app/main.py, этот файл — корень сервера. src/app — это модуль приложения, в котором содержится общая/основная логика приложения, такая как база данных, базовый репозиторий, конфигурация и т. д. Эти файлы являются расширенной копией логики, представленной в документации FastAPI. Следующим шаблоном проектирования является шаблон проектирования репозитория, поскольку существуют ORM для таблиц и служб, которые выполняют логику и манипулируют данными.

  1. Модуль аутентификации — это место, где живет логика аутентификации пользователя, включая модели, сервисы, репозитории, схемы и маршрутизаторы.
  2. Модуль учетных записей — это место, где сосредоточены финансовые действия, ориентированные на пользователя, включая модели, службы, репозитории, схемы и маршрутизаторы.
  3. Миграции модуль — это место, где живут версии миграций БД, созданные Alembic.
  4. Модуль Pipes является адаптацией NestJs, здесь я использую логику для управления доступом на основе ролей.
  5. Тесты, как следует из названия, тесты были написаны для всего приложения.

Задачи

Создание и регистрация учетной записи пользователя

Это довольно просто, нужен маршрут для регистрации и входа в систему, вот что такое модели (таблица БД для пользователя).

User Class Model for the DB using Base from SQLAlchemy

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

Есть два способа регистрации: один для обычных пользователей, а другой для суперпользователей.

Routes for registration for Users and another for Admins

В соответствии с поставленной задачей существует два класса пользователей: администраторы и обычные пользователи, и была конкретная инструкция, чтобы дать новым пользователям баланс 1000. В идеале, каждый пользователь должен иметь баланс по умолчанию 0. Здесь идет сложная часть software, в инженерном сообществе состоялся разговор, где люди с опытом работы в финтех говорили о том, как хранить числа. Решений было много, не буду вас утомлять, но был консенсус не хранить деньги в виде Int или float. Это побудило меня провести мини-исследование, и я наткнулся на ветку Reddit, в которой говорилось о том, как хранить деньги с помощью пакета под названием . Decimal, который предотвращает переполнение, возникающее с Float.

Вот как я создал баланс по умолчанию для обычных пользователей: после успешного создания новой записи пользователя я создал запись баланса учетной записи.

creating a default account balance based on the instruction

Вот как выглядит таблица учетных записей.

Account table for storing user account balance

Эта таблица предполагает, что у нас может быть более одной записи в БД, для моей реализации у нас есть только запись, но я объясню кое-что, что я сделал бы, если бы я строил это как реальную компанию в угольках этой статьи.< /p>

Мы выполнили две задачи, упомянутые выше, авторизацию пользователя и баланс по умолчанию.

Переводы и транзакции

Теперь мы смотрим на переводы. Социальная игра финансовых технологий заключается в возможности принять или отклонить перевод.

Есть кое-что, о чем мы должны кратко рассказать, это называется состоянием гонки.

<цитата>

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

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

Я попытался предотвратить состояние гонки, используя несколько методов, и я выделю их,

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

Я считаю, что эта проверка очень важна и может предотвратить появление условий гонки и отрицательного баланса.

Can I carry out this transaction pipe for transfer route

create method in the transaction service

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

Transaction table for storing transaction logs for users

Здесь перевод отправляется, а отправитель вычитается, однако комиссия за перевод еще не переведена на счет отправителя. Для его перевода отправленные средства должны быть приняты. Существует канал, гарантирующий, что действующее лицо отправленного средства действительно является получателем перевода.

Это также предотвращает действие по перезаписи, получателю разрешено два действия «Принять» или «Отклонить». После того, как транзакция выполнена, дальнейшие действия невозможны.

Am I the receiver pipe to prevent no receiver from carrying out an action.

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

Update method for the transaction service

Из задачи выше выполнение переводов, а также принятие и отклонение перевода теперь завершены.

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

Канал is_reverted_dep позволяет администратору отменить транзакцию, только если ее статус был принят или отправлен, и только эти действия. Это предотвращает мошенническую атаку с чрезмерным кредитованием отправителя.

Can I revert this transaction pipe for only admins

Этот канал позволяет выполнять действия, только если вошедший в систему пользователь является администратором.

Is logged in user an admin pipe

С помощью этих фрагментов основной логики я продемонстрировал свой мыслительный процесс для подхода к социально-финтех. Код доступен по пути /docs (благодаря FastAPI), и я также отправил документацию почтальона в read me из репозитория.

Что бы я сделал, если бы я создавал настоящий продукт?

  1. Пользователь знает своего клиента, существуют легкодоступные сторонние решения, которые можно интегрировать в зависимости от вашей страны.
  2. Взимать небольшую плату за транзакции (что позволяет продукту зарабатывать).
  3. Бесплатные переводы в начале каждого месяца (это делает KUDA Bank), это можно сделать с помощью периодического задания сельдерея, которое выполняется раз в месяц.
  4. Баланс счета в нескольких валютах, что позволяет пользователям зарабатывать в разных валютах.
  5. Выставление счетов (есть интересующий меня продукт, созданный с помощью FastAPI).
  6. Если бы это был SDK основного продукта для интеграции с продуктами.
  7. Аккаунт разработчика с тестовой средой и ключами API.

Это еще раз доказывает, что приложение Python обширно и не знает границ, а только то, что мы для него определяем. Код для Finbanker доступен здесь.


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE