Size: a a a

Software Design/Architecture/Zen

2021 August 02

PD

Philipp Dolgolev in Software Design/Architecture/Zen
Это не совсем правда. Встречаются вполне себе бизнесово атомарное множество проводок. Можно тут конечно пытаться это неатомарно делать в БД, но пока от этого больше сложности и проблем, нежели бонусов.
Ну и опять же, снэпшоты балансов подбивать можно асинхронно, а в моменте смотреть на снэпшот+проводки. Но тут уже больше зависит от конкретных нагрузок, и тонкого тюнинга.
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
Ну оно же зависит, как всегда. Кому-то не надо, а по хорошему - надо. Если у вас финтех - точно надо )
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Да не все используют SQL базы даных
Вот вам DynamoDb в руки и баста
Не люблю бизнес логику завязывать на базу данных  а не на код.
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
С мой точки зрения, тут есть перевод/платеж/транзакция, и в рамках него есть множество проводок(это если про двойную запись говорить).
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
> Вот вам DynamoDb в руки и баста
А я люблю брать инструмент под задачу, а не задачу на инструмент натягивать 🙂 SQL отлично для финансов заходит, особенно там - где и хочется иметь все эти гарантии SQL.
источник

SB

Sergei Baikin in Software Design/Architecture/Zen
Та я же не против как пример привел
Это нормально перекладывать на бызу данных твественность ибо доверять современным разработчикам такое себе решение 😄
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну да ну да, овердрафты например
источник

SP

Sergey Protko in Software Design/Architecture/Zen
источник

SP

Sergey Protko in Software Design/Architecture/Zen
вот просто для вдохновения
источник

SP

Sergey Protko in Software Design/Architecture/Zen
на тему консистентности и финансов
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
Овердрафты же про знак баланса, и именно что уже "бизнесовые" требования/ситуации в реальном мире.
В моем случае от БД мне нужны именно что транзакционность да FK по большому счету.
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
Спасибо, гляну, может чего открою для себя еще
источник

VS

Vladimir Smirnov in Software Design/Architecture/Zen
двойная запись появилась за миллиард лет до ДДД, программирования и компьютеров, зачем придумывать велоспиед)
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
Подождите, двойная запись - это хорошо!

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

SP

Sergey Protko in Software Design/Architecture/Zen
а еще хочется быстро производить расчеты
источник

SP

Sergey Protko in Software Design/Architecture/Zen
а еще банки зарабатывают немало денег на овердрафтах
источник

SP

Sergey Protko in Software Design/Architecture/Zen
а еще есть межбанковские переводы, ну и вот в видосе выше там в целом весьма интересные кейсы на тему сроков действия чеков и платежей
источник

PD

Philipp Dolgolev in Software Design/Architecture/Zen
Безусловно, но на пути расчета еще отрабатывает различный антифрод/ТМ, коммуникации вообще со внешними платежными сервисами, что занимает много больше времени, что атомарный инсерт в SQL DB, я не прав?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
всем хочется что бы вжух и консистентно атомарно. Но реальность чуть сложнее и бизнес по большей части оперирует с eventual consistency в реальности
источник

SP

Sergey Protko in Software Design/Architecture/Zen
да, занимает, и если это затрагивает 0.1% пользователей то можно проектировать систему так что бы остальным 99.9% ждать не надо было
источник