It appears that there are multiple levels of abstraction addressed in this article. At the foundational level, a financial system necessitates an append-only database, ledger, or register to ensure data integrity and immutability. Building upon this foundation, we handle events, transactions, and behaviors that represent the dynamic aspects of the system. Beyond this layer, we enter a domain where certain situations may permit the updating of existing data or records, corresponding to your state machine abstraction. Finally, either above or parallel to these layers, communication interfaces such as REST APIs can be utilized to translate these financial situations into client-server interactions.
I believe that all these levels are essential in designing a robust financial system. I agree that people often assume simple solutions will suffice, but in reality, they do not account for the complexity and nuances inherent in financial systems. In the article you mentioned, you articulated one of the most significant financial arguments: "It is impossibly difficult to retroactively 'make them right'." This underscores the importance of designing systems that prevent errors upfront rather than attempting to correct them after the fact. I think this could be the central point of our fascination with financial, governmental, and similar systems, where the cost of retroactive corrections can be prohibitively high.
It appears that there are multiple levels of abstraction addressed in this article. At the foundational level, a financial system necessitates an append-only database, ledger, or register to ensure data integrity and immutability. Building upon this foundation, we handle events, transactions, and behaviors that represent the dynamic aspects of the system. Beyond this layer, we enter a domain where certain situations may permit the updating of existing data or records, corresponding to your state machine abstraction. Finally, either above or parallel to these layers, communication interfaces such as REST APIs can be utilized to translate these financial situations into client-server interactions.
I believe that all these levels are essential in designing a robust financial system. I agree that people often assume simple solutions will suffice, but in reality, they do not account for the complexity and nuances inherent in financial systems. In the article you mentioned, you articulated one of the most significant financial arguments: "It is impossibly difficult to retroactively 'make them right'." This underscores the importance of designing systems that prevent errors upfront rather than attempting to correct them after the fact. I think this could be the central point of our fascination with financial, governmental, and similar systems, where the cost of retroactive corrections can be prohibitively high.