4 ms·
I believe you want "one log" in the logical sense. In theory, you could have "one log" per user or group of users, or whatever sharding technique makes sense fo
by hcarvalhoalves 2y ago
I believe you want "one log" in the logical sense. In theory, you could have "one log" per user or group of users, or whatever sharding technique makes sense for multi tenancy model. It can also be "one log" per bounded context - e.g. the entire payment pipeline in one log.
- sewen 2y agoYes, exactly right. One log per logical entity, here "payment ID". The way our open source project implements that is with a partitioned log and indexes at key-granularity, so it is like virtually a log per key.
- ianburrell 2y agoHow do you deal with one side of transaction getting lost? Traditional double entry accounting puts entry for each side of the transaction. It will cause problems if one side is lost or delayed. How do you handle transactions in general? It is pretty common to have multiple changes that need to be applied together. In a single log, can write the changes and then write a record that says the changes are committed. This is how databases work.
- hcarvalhoalves 2y agoYou can simplify things significantly if you can maintain a 1:1 mapping of log entry to transaction (in the business sense). This way you advance the state of your system in discrete steps by advancing in the log, and can make rewind easier too.
- mrkeen 2y agoThat's what the rest of us are doing in event-sourcing land, but TFA is arguing for something much stronger: If everything’s in one log, there’s nothing to coordinate The rest of us have to coordinate the logical log of user creation/deletion and the logical log of user payments, etc. Separate logical logs with no need for coordination can only work if they are truly independent systems - no causality between them.