About

This is a toy project I started in order to register some patterns/utils so I can quickly recall them when I think "hey, I did this before once, how was that again?". It should be of no interest to anyone but my future self.

Internal logic consistency and correctness is upheld strongly by the compiler and the type system along with unit tests. Parsing and external interactions correctness are confirmed by unit tests (some are integration tests in disguise).

Beisde the natural assumptions, I have a couple more:

• Any transactions that result in invalid state are logged to stderr and ignored;
• No one will ever dispute a Withdrawal transaction;
• A frozen bank account can't deposit or withdraw, but disputes may still be raised and settled

transactions.csv contains very basic test data just to make sure that the binary correctly handles arguments and input and output formats, the real tests are in the code.

Overkills

Is some (most?) of this design overkill? Definitely! But the point is to showcase and assume that this is a system that will scale in demand as well as features, so it must be robust and performant. Hence the:

• useless use of async, given that there's no actual concurrency (when I went for async I thought I was going to do the channel thing described below);
• currently oversimplified and absurd implementation of a custom decimal number just to save half the memory on amounts and some math computational cost, when the likely performance bottleneck is the HashMap related stuff; sure, there's also extra type safety due to typed signedness, but still...
• using the type system to enforce transaction rules, when they are too simple for such a need (still, this could be pushed waayyy further, as the comments mention; it would just be too much boilerplate and readability penalty for my personal taste)

At some point I thought of separating the Ledger into 2 components that would communicate using channels, to simulate a client database in one system and the transactions in another, but I'll leave that for another day.