Go to file
Артем 75592f2a54
TD-428: More tests and routing light refactor (#49)
* added cascade with limits test

* added machine test tool and limit complex test

* refactored routing

* fixed

* fixed log

* added requested changes

* fixed

* refactored ct machine

* Revert "Auxiliary commit to revert individual files from a2e126e6aeb8c71cde2d2b2560270ab5d25bf49f"

This reverts commit 58c9951ac2830dda4d17f2e920e1d66c72c4fd33.

* refactored test tool

* refactored test

* fixed format

* cleaned up

* fixed

* added minor

* added one more test

* changed to gen server

* fixed

* removed

* fixed types

* added patch

* fixed
2022-12-02 14:47:28 +04:00
.github/workflows Update valitydev/erlang-workflows action to v1.0.10 (#33) 2022-11-24 16:08:00 +04:00
apps TD-428: More tests and routing light refactor (#49) 2022-12-02 14:47:28 +04:00
config TD-330: Limiter (#35) 2022-08-04 12:18:02 +03:00
test TD-330: Limiter (#35) 2022-08-04 12:18:02 +03:00
.dockerignore TD-170: Add CI/CD (#4) 2022-03-02 11:20:07 +03:00
.env TD-366: Make session finalization idempotent (#42) 2022-08-29 17:42:46 +03:00
.gitignore TD-170: Add CI/CD (#4) 2022-03-02 11:20:07 +03:00
docker-compose.yml TD-454: Add allow support (#50) 2022-12-01 18:35:44 +04:00
Dockerfile TD-273: Drop legacy routing facility (#23) 2022-04-21 14:02:52 +03:00
Dockerfile.dev TD-273: Drop legacy routing facility (#23) 2022-04-21 14:02:52 +03:00
elvis.config TD-428: More tests and routing light refactor (#49) 2022-12-02 14:47:28 +04:00
LICENSE Update file(s) from valitydev/.github 2022-02-21 21:37:41 +00:00
Makefile TD-365: Continue trying to create a withdrawal when no binbase data is available (#38) 2022-08-03 14:32:56 +03:00
README.md Handle transfers through noion of accounts (yeah, again) (#9) 2018-07-16 17:21:17 +03:00
rebar.config TD-330: Limiter (#35) 2022-08-04 12:18:02 +03:00
rebar.lock TD-454: Add allow support (#50) 2022-12-01 18:35:44 +04:00
renovate.json Add renovate.json (#1) 2022-02-21 20:24:13 +03:00

Fistful

Wallet Processing Service

Development plan

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

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

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

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

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

Поддержка checkout

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

Коммуналка

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

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

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

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

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