Никита Мельников — Использование акторной модели в системах финансовых транзакций

Ближайшая конференция — JPoint 2025, 3–4 апреля (Москва + трансляция).
— —

В fintech-мире, где скорость и надежность — ключевые параметры, эффективное управление конкурентными процессами становится критически важным для поддержания целостности данных и операционной эффективности.

В докладе рассмотрели использование Actor Model в системах обработки денежных переводов.

Поговорили о том, как Kafka помогает создать устойчивое решение, которое минимизирует проблемы, связанные с конкурентностью. Показывая, что идеальная конкурентность — это ее полное отсутствие.

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

[s_konik]

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

1. Клиент перестал ожидать завершения запроса - ок, перевели задачу в асинхронную.
2. Как ушла потребность не использовать SELECT FOR UPDATE не совсем понял - мы разбили всю транзакцию на 2 актора/консьюмера?
Правильно я понимаю эти шаги?
2.1 сначала посылаем сообщение актору, который проверяет принадлежность к санкционным спискам,
2.2. актор в случае успеха посылает сообщение другом актору, который деньги переводит, но вот тут все равно нужно убедиться, что мы проблему LOST UPDATE решили. То есть внутри этого актора будет какой-нибудь OPTIMISTIC LOCK.

Получается, акторная модель превратила много LONG LIVED TRANSACTIONS в много-много SHORT LIVED TRANSACTIONS, так?
Якобы часть ожидания локов из БД превратилась в ожидание очереди задач для актора, но внутри самих акторов транзакции быстро проходят.

[vladpron]

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

[АндрейИванов-бвч]

трансферов может быть тысячи, значит 1 000 партиций нужно?

[oleksandrvasylchenko]

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

[sergey]

Надеюсь, в тиньке не он делал финтранзакции)

[МаксимАлексеев-чй]

Самый простой способ решения LOST UPDATE, почему-то, не рассмотрели - без явных локов, без распределенных транзакций.
BEGIN;
UPDATE transfers SET status = 'PAYMENT_RECEIVED' WHERE id = 1 AND status != 'CANCELLED';
COMMIT;

А для транзакции, которая отменяет трасферы:
BEGIN;
UPDATE transfers SET status = 'CANCELLED' WHERE id = 1 AND status != 'PAYMENT_RECEIVED';
COMMIT;

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