Hellgate

Core logic service for payment states processing.

Building

To build the project, run the following command:

$ make compile

Running

To enter the Erlang shell with the project running, run the following command:

$ make rebar-shell

Development environment

Run in a docker container

You can run any of the tasks defined in the Makefile from inside of a docker container (defined in Dockerfile.dev) by prefixing the task name with wc-. To successfully build the dev container you need Docker BuildKit enabled. This can be accomplished by either installing docker-buildx locally, or exporting the DOCKER_BUILDKIT=1 environment variable.

Example

• This command will run the compile task in a docker container:

$ make wc-compile

Run in a docker-compose environment

Similarly, you can run any of the tasks defined in the Makefile from inside of a docker-compose environment (defined in docker-compose.yaml) by prefixing the task name with wdeps-. To successfully build the dev container you need Docker BuildKit enabled (see Run in a docker container section). It may also be necessary to export a COMPOSE_DOCKER_CLI_BUILD=1 environment variable for docker-compose container builds to work properly.

Example

• This command will run the test task in a docker-compose environment:

$ make wdeps-test

Documentation

@TODO Please write a couple of words about what your project does and how it does it.

Fistful

Wallet Processing Service

Development plan

Бизнес-функционал

• Минимальный тестсьют для кошельков
• Реализовать честный identity challenge
• Запилить payment provider interface
• Запилить контактные данные личности
• Запилить нормально трансферы
• Заворачивать изменения в единственный ивент в рамках операции
• [.] Компактизировать состояние сессий
• Запилить контроль лимитов по кошелькам
• Запилить авторизацию по активной идентификации
• Запилить отмену identity challenge
• Запускать выводы через оплату инвойса провайдеру выводов
• Обслуживать выводы по факту оплаты инвойса

Корректность

• [.] Схема хранения моделей
• Дегидратация
• Поддержка checkout
• Коммуналка

Удобство поддержки

• Добавить служебные лимиты в рамках одного party
• Добавить ручную прополку для всех асинхронных процессов
• Вынести ff_withdraw в отдельный сервис
• Разделить development, release и test зависимости
• Вынести части ff_core в genlib

Поддержка checkout

Каждая машина, на которую мы можем сослаться в рамках асинхронной операции, должно в идеале давать возможность зафиксировать версию своего состояния посредством некой ревизии. Получение состояния по ревизии осуществляется с помощью вызова операции checkout. В тривиальном случае ревизия может быть выражена меткой времени, в идеале – номером ревизии.

Коммуналка

Сервис должен давать возможность работать нескольким клиентам, которые возможно не знают ничего друг о друге кроме того, что у них разные tenant id. В идеале tenant должен иметь возможность давать знать о себе динамически, в рантайме, однако это довольно трудоёмкая задача. Если приводить аналогию с Riak KV, клиенты к нему могут: создать новый bucket type с необходимыми характеристиками, создать новый bucket с требуемыми параметрами N/R/W и так далее.

Дегидратация

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

Служебные лимиты

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