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

Spanner сам все шардирует(шарды еще и с паксос протоколом), спаннер обеспечивает транзакционность (через two phase commit), то есть для клиента он выглядит как acid бд. Они отдельно ничего не должны были поверх него лепить.

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

two phase commit - это не транзакционность, а eventual consistency.

Почему вы так думаете? Почитайте статью спаннер 2012 года, там объясняется как они достигают транзакционность, могу кратко пересказать. Но суть в том, что транзакционность есть, этим спаннер очень удобен

А как двойна запись помогает в этом? Деньги уходят с карты в никуда же.

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

в общем, я к такому выводу пришел.

Я внимательно не читал, из того, что я сейчас насканил - они Spanner используют только для хранения данных (DDD-агрегатов), а поверх него у них добавлена своя логика для обеспечения консистентности _между_ агрегатами. Насколько я понимаю, транзакционное изменение сразу двух books не гарантируется, но их логика гарантирует консистентность в рамках предметной области.

Если у тебя БД влезает в одну СУБД и ты все изменения делаешь в больших транзакциях, то тебе двойная запись не нужна. А если одной СУБД не хватает, то без двойной записи не обойтись, т.к. агрегаты счетов могут быть расположены в двух разных СУБД в одном кластере. И тебе нужно так или иначе обеспечить изменение информации и в одной и в другой СУБД. А это делается либо 2PC либо с помощью передачи сообщений (например, в рамках паттерна "Сага"). В любом случае у тебя уже не остаётся опции "залочить все СУБД кластера" для сохранения проводки.

Ну это да, это согласен.

Ну, честно говоря я плохо себе представляю задачу, когда все счета не влезают в одну СУБД )

Обычно проблема не в самих счетах, а то что запись их изменений не влезает в IOpS железки.

геораспределенная биржа торгующая 100500 торговых пар

Ну, сейчас IOPs уже не проблема

🔥🔥🔥Через пять минут, в 18:00 присоединяйтесь к митапу "Декрет на пике карьеры".

Вместе с Натальей Симахиной разберём основные страхи работающей мамы, ответим на вопрос, существует ли баланс между материнством и карьерой и можно ли выйти из декрета с повышением. Наталья расскажет, какие soft skills помогут молодой маме и в декрете, и на совещании.

https://youtu.be/ArRSKcV2NGY

Неожиданно,я думал тимлид это хрень а не карьера
(и при нагреве как сказал Олег Сорока - майонез распадается на жир и воду; а тимлид или в девы или в манагеры)

И как же она решена? Пострайпать данные можно до определенного предела. Если ты делаешь OLTP систему на одном шарде, ты в итоге упрешься даже не в бинлог, а в индексы.

1mln iops на nvme уже вполне достижим. Больше нужно только для бирж, но там свои особенности.

Проблемы начинаются уже у крупных мерчантов..