Caveats that make this not production worthy

[craigspaeth]

This couldn't be a replacement for Causality for various reasons that I'll try to list here.

1. To ensure strict real-timeness we want to ensure that we process each event one at a time to avoid a race condition where someone who places a bid milliseconds after of someone else doesn't end up being accepted first because their bid was processed faster (e.g. b/c of a geographically closer database). That means the code that fetches > validates > appends the new event must all happen at once before the next event runs that code. To achieve this in Causality now we use actors in an "atomic" fashion.
2. In a production system, we'd likely add more servers for redundancy. That means when we broadcast the updated state to all users we would need to use a messaging queue to synchronize the updates across node servers.
3. Obvious things like missing tests and typical application robustness stuff.

[craigspaeth]

Speculating on a couple alternative solutions to 1:

1. Ironically the most low-scale system possible like a single synchronous server would ensure that each request is blocking and therefore events are processed in order.
2. The app server could store a timestamp before processing the event and persist it after it accepts the event. The event list would then simply need to be sorted by that timestamp when pulled from the database.
3. We could signal a lock on a row/document in the database before processing the event, and unlock it afterward.
4. We could write a stored procedure of some sort to have the database validate the event, ensuring it's processed in one-go 🤢
5. We could ignore validation against the event list and allow things like bids below asking price to be appended—then clean out the invalid events upon broadcast 🤢
6. We could accept the chance of this likely very rare race condition because at the end of the day the LAI is only as real-time as the human eyes of the auctioneer and the machine isn't really responsible for determining the outcome. e.g. The lot doesn't close until the auctioneer says so, and if someone's bid is accidentally processed before someone elses, they can just up their bid. I'm sure, today, we don't account for the latency advantage of someone bidding closer to our servers which could possibly be a bigger advantage than the randomness of time between app and database servers. 🤷‍♂️

[damassi]

1 and 2 seem simple enough!

[craigspaeth]

Agreed @damassi however 1 does seem dangerous b/c anyone could trip over the server wire and shut down the whole thing 😛 That said, a load balancer configured to failover immediately to another single server could easily mitigate that, but you still risk a high traffic auction being clogged up by processing bids (that might be a non-concern/unavoidable). I moved this to my big architecture thread, so plz feel free to comment there. Locking this one.