3 ms·

You think transactional updates are a mistake? I guess you’ve never had to worry about the integrity of your data? Bank -> debit card purchase -> perform all r

You think transactional updates are a mistake? I guess you’ve never had to worry about the integrity of your data? Bank -> debit card purchase -> perform all required database work in a transaction -> transaction fails -> decline debit card purchase Without transactions, in this scenario, maybe the debit card transaction fails but money is still taken out of your account? Doesn’t sound very pleasant.

lmm 5y ago
Database transactions would be useless for banks - you'll notice that if you try to pay while not having enough money in your account, the attempt doesn't simply disappear. What banks actually do is something akin to what Kafka-based systems do - the attempt to charge is recorded in a leger, and then fulfilment of that happens asynchronously.
- KptMarchewa 5y ago
  That's seriously one of the worst takes I've seen on this website. >the attempt to charge is recorded in a leger Hint: how do you think this attempt is recorded and fulfilled? Or, do you think "it's just appended" and bank recalculates your balance from scratch every time you spend 1$ on coke can? Only bank I've heard of that's not using traditional relational database for ledger is Monzo [1] - but they still use Cassandra's transactions. [1] https://www.scaleyourapp.com/an-insight-into-the-backend-infrastructure-of-a-modern-digital-bank-monzo-architecture/ https://www.scaleyourapp.com/an-insight-into-the-backend-inf...
  - lmm 5y ago
    > Hint: how do you think this attempt is recorded and fulfilled? Or, do you think "it's just appended" and bank recalculates your balance from scratch every time you spend 1$ on coke can? That's how the bank I worked with did it. Of course there was caching in place so we didn't actually recompute everything every time, but the implementation of that was a lot closer to "commit a kafka offset" than an RDBMS-style transaction. (E.g. we didn't overwrite the "current balance" in-place, we appended a new "current balance as of time x").
    - dmitriid 5y ago
      > Of course there was caching in place so we didn't actually recompute everything every time I think you've proved our point
    - johnthescott 5y ago
      every large ingest app i have worked on had something akin to kafka, from raw 3d seismic broadcast via sat, to RF tower motion detection, to carrier grade cellular billing. common denominator was a replayable ingest queue. yes, kafka is a "great" idea. however, it is not a replacement for querying.
- marcosdumay 5y ago
  The reason the things are called "transactions" is because they were invented for banks. Bank ledgers must always be appended in pairs or not at all, never in any other number. The entire finance system is dependent on that feature. Transactions were kept by humans, literally for a few centuries, before the algorithm was adapted for computers.
  - lmm 5y ago
    RDBMS "transactions" work nothing like banking transactions; when you abandon a banking transaction you don't erase it as though it never happened, you keep a full record of what happened but the downstream consequences change. In fact the way traditional accounting is done, with transactions first committed to journals and then later asynchronously propagated into ledgers, is more closely akin to how Kafka-based systems work.

lmm 5y ago

Database transactions would be useless for banks - you'll notice that if you try to pay while not having enough money in your account, the attempt doesn't simply disappear. What banks actually do is something akin to what Kafka-based systems do - the attempt to charge is recorded in a leger, and then fulfilment of that happens asynchronously.

KptMarchewa 5y ago
That's seriously one of the worst takes I've seen on this website. >the attempt to charge is recorded in a leger Hint: how do you think this attempt is recorded and fulfilled? Or, do you think "it's just appended" and bank recalculates your balance from scratch every time you spend 1$ on coke can? Only bank I've heard of that's not using traditional relational database for ledger is Monzo [1] - but they still use Cassandra's transactions. [1] https://www.scaleyourapp.com/an-insight-into-the-backend-infrastructure-of-a-modern-digital-bank-monzo-architecture/ https://www.scaleyourapp.com/an-insight-into-the-backend-inf...
- lmm 5y ago
  > Hint: how do you think this attempt is recorded and fulfilled? Or, do you think "it's just appended" and bank recalculates your balance from scratch every time you spend 1$ on coke can? That's how the bank I worked with did it. Of course there was caching in place so we didn't actually recompute everything every time, but the implementation of that was a lot closer to "commit a kafka offset" than an RDBMS-style transaction. (E.g. we didn't overwrite the "current balance" in-place, we appended a new "current balance as of time x").
  - dmitriid 5y ago
    > Of course there was caching in place so we didn't actually recompute everything every time I think you've proved our point
  - johnthescott 5y ago
    every large ingest app i have worked on had something akin to kafka, from raw 3d seismic broadcast via sat, to RF tower motion detection, to carrier grade cellular billing. common denominator was a replayable ingest queue. yes, kafka is a "great" idea. however, it is not a replacement for querying.
marcosdumay 5y ago
The reason the things are called "transactions" is because they were invented for banks. Bank ledgers must always be appended in pairs or not at all, never in any other number. The entire finance system is dependent on that feature. Transactions were kept by humans, literally for a few centuries, before the algorithm was adapted for computers.
- lmm 5y ago
  RDBMS "transactions" work nothing like banking transactions; when you abandon a banking transaction you don't erase it as though it never happened, you keep a full record of what happened but the downstream consequences change. In fact the way traditional accounting is done, with transactions first committed to journals and then later asynchronously propagated into ledgers, is more closely akin to how Kafka-based systems work.