If you build a state machine on top of a relational database you can abstract concurrency problems away from your business logic and allow developers to write safe-by-default code without dealing with concurrency concerns. This post explains how to build a library that offers those protections, and how they work under-the-hood.
That much is clear, the question is: why is it needed at all? The sort key has the same uniqueness constraint, so there cannot be two entries with the same sort key value. So under which circumstances does the highest sort key value not reject the most_recent transaction?
I guess separation of concerns? One is for the system, one is for display?
A unique Boolean is easier to query than sorting and limiting?
Maybe you don’t ever need the ability to display a history, but you still want the history (instead of just making the transaction_id unique constrained)… so you just drop the sort_order column?
I understand what you are saying.
Maybe that’s just how they went about it. Originally planning on using created_at to do the ordering, then later realising that a customisable sort_order is required so they can make things make sense without having to fudge timestamps.