In practice, many teams start with a regular database and application-level accounting logic. At some point, retries, race conditions, and reconciliation issues appear.
I'm curious how engineers here decide: — when is a plain database no longer enough? — what signals that accounting logic should move into a dedicated ledger runtime? — have you experienced incidents where deterministic replay or auditability would have helped?
Looking for engineering perspectives, not product discussion.
daulet_b•1h ago
I’m working on an internal ledger runtime (not a blockchain, not a payment system) and we kept running into cases where a database + application logic wasn’t enough to guarantee accounting invariants across services.
Typical problems were: – retries breaking balances, – race conditions across microservices, – difficulty explaining “where the money went” after incidents.
I’m curious how others here draw that line in practice: At what point did you decide a database was no longer sufficient? Was it an incident, scale, regulatory pressure — or did you decide a ledger was overkill after all?