I have a question about active replication and ordering. I am aware that traditionally active replication in a distributed system requires total ordering to propagate requests to replicas, however, I have thought of an example where may this wouldn't be necessary.
Picture a bank account system using active replication. But instead of being able to debit your account, you can only credit your account (so only add positive amounts to your balance). Does the banking system need ordering guarantees then? Considering if I were to add £5 then £10 to my account, if the replicas did not receive this in order, it would still amount to £15 regardless of the order they have received the request in. There's no real conflicts that could arise for ordering, a part from the fact the user may be a bit annoyed to see that their account only has £5 in it when they credit £10 first. But more technically, where is the problem?
I imagine I'm wrong, but can't really see why. Would someone be able to explain to me in a bit more detail?
Yes, addition is commutative. This means that any ordering of additions will result in the same value. Total ordering is usually required for setting values, but not for increments. However, increments require exactly once delivery. If that increment arrives twice, because the sender didn't realize that the receiver got it, you just gave someone £10 of your own money. Setting the account balance to an exact value is sensitive to ordering, but not to retrying.
The problem for banks is that you usually have some other correctness guarantees you need to hold, such as the account balance for any account never being negative. If you stored the money in and money out of an account in two fields next to each other, by simply having working as you described and the other one only storing the subtractions, you would be able to handle both inserting money into and paying from an account. The ordering matters now, though, since you could get all the subtractions first, and then the additions. Or all the additions, then you pay using that money before the subtractions get synced over, and now you've overdrawn your account.
I have three recommendations: First, don't build software handling money if you can avoid it. Bugs are very expensive. Second, don't design distributed systems unless you really need to. Third, if you have to, store the transactions instead of the accounts, and use a UUID. Alice sent £8 to Bob (roughly on January 22). This is something called a CRDT, which handles duplicates, and often handles arbitrary ordering.