zdcthomas / toy_marketplace

Toy marketplace challenge

See project specification for more details

Arch decisions

Mutative vs immutable functional design:

Usually I strongly lean toward a more functional approach. Usually I would create a struct which tracks holds the current state of all clients/transactions and have the handle transaction function recursively move through this list, and ultimately return a final version of this state. However, for performance and lifetime reasons, I opted for a mutating-in-place strategy.

To async, or not to async

Try as I might, I could not find a good way to process this list more asynchronously, without running a first pass that groups all related transactions together. This felt silly.

Not storing meta transactions

I made a distinction between standard transactions (e.g deposit, withdrawl) and meta transactions (e.g dispute, chargeback, resolve).

This is primarily because meta transactions didn't have a meaningful transaction_id, and instead, use their transaction_id field to reference another transaction, so I would either have to store the transactions in a Vec and cause every transaction lookup to happen in O(n), or I could store just the standard transactions in a HashMap associated to their id.

I tried the former first, but the later turned out to make more sense when meta transactions can change the state of an existing transaction (i.e dispute them).

I don't love that transactions are mutable in this design. I'd rather they be completely immutable in an append only list, but keeping track of disputes would have added a bunch of complexity (probably in the form of an entire other data structure for the meta transactions).

This is main decision I'd reevaluate if I had more time.

If I had more time

Test coverage

Right now the test coverage is fairly spartan, and I'd like to shore it up more, especially with some larger integration tests.

Remove nearly all expects

There are a few truly impossible states in this app, and in some of these states (especially None values when retrieving from lists) I opted for simply expecting or unwrapping these values. But other times there are states that are only possible through function misuse, and these I should be bubbling up.