[hodgesrm]

I would just put the ledger in a database table if it's that important and maintain the current state of the account in a separate table. ACID transactions and database constraints make this kind of consistency easier to achieve than many alternatives. It's also easier to prove correctness since you can run queries that return consistent results thanks to the isolation guaranteed by ACID. (Modulo some corner cases that are not hard to work around.)

Just my $0.02.

[mrkeen]

> ACID transactions and database constraints make this kind of consistency easier to achieve than many alternatives.

If your company only runs one database.

> It's also easier to prove correctness

RDBMSs are wonderful and I don't consider them unreliable at all. But I can't prove the correctness of my teammate's actions. I want them to show their working by putting their updates onto an append-only ledger.

[jacques_chester]

> If your company only runs one database.

I think the same argument can be made with "only one Kafka cluster" and "only one blockchain".

[lmm]

> I think the same argument can be made with "only one Kafka cluster"

No it can't. Kafka events for the same partition will always be processed in order. If you have a stream transformation that reads from a topic that lives in one cluster and writes to a topic that lives in another cluster, then (as long as you chose the right partition key) everything will work correctly. Even if you have a sequence of transformations that zig-zag between two different clusters, it will do the right thing. You can't achieve that with traditional databases.