Comments by "Aden Wellsmith" (@adenwellsmith6908) on "Continuous Delivery"
channel.
-
Some bits coming out of the inquiry are interesting. One bit I saw stated that a transaction was taking 10 seconds, locking the system for that period of time.
A bit more digging and its clear they didn't build it as a distributed system. For example, if you have a Point of Sale system, then updating the accounts in real time is not a requirement.
What you should do is separate off the book keeping, with a queue between the POS and the Accounts. POS does its transaction, puts it on a queue. That's fast. The back end then pulls the transaction off and handles it. No need for the transactions to be synchronous. A proper fault tolerant queueing system is needed. MQ for example.
1. I bet they were using raw SQL to update the database
2. Accounting entries. Never ever delete. Reverse and rebook, with links between the transactions.
3. Integrity constraints, on the DB
4. Full audit trail, with records written to a write only log.
5. A proper role based security system and that includes the accounts for the technical users [eg. Cron jobs]
6. Integrity reports just for it integrity.
Another issue, I bet the accountants designing the system didn't understand IT. And the IT staff didn't understand accounting.
For example, how many people understand that double entry is a consequence of the accounting equation, not a fundamental principle?
1