> git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important.

In fact, we had it in mind when we designed TigerBeetle [1][2], a financial accounting database to do a million financial transactions a second.

We started with the data structures, made sure that these were one or two cache lines to reduce cache misses and perfectly aligned to eliminate false sharing, and then we added built-in accounting primitives to move the code to the data, instead of the data back and forth across the network to the code, which is how these kinds of balance tracking systems that we were working with before were typically implemented.

The result is much simpler, a perfect replicated state machine, and also much safer, because the business logic and data are executed within the state machine, protected by the distributed consensus protocol (Viewstamped Replication Revisited by Liskov and Cowling), rather than a mess of SQL transactions spanning multiple distributed systems, all with different clocks.

[1] https://github.com/coilhq/tigerbeetle

[2] Guess what language we wrote it in? And this is making more and more sense, like a secret weapon. The community is amazing, deeply talented, with great taste, and at the vanguard of where things are going for these kinds of systems.