OK, so this is standard, and that’s (most definitely) good. If your’e not using any in-process session-state, then there’s no need for mutexes except for things like connection-pools, the actual network runtime, etc. It’s possible that RPCs to backend systems might need to run in parallel, and for that you might want to write a little thread-pool-based harness to manage backend RPCs, but that would be it.
Which leads me to ask: why bother with monadic concurrency? I mean, what’s it buying you? [other than, as Vincent was very honest to say, publications] You have no actual interference between concurrent trans, since they share no state. Why bother with all the extra work and mental model?
ETA: you can assume I know how modern (and pre-modern) web-app systems are built: I spent my career debugging web-app dumpster fires, including at Twitter in the summer of 2008. So none of this is unfamiliar; to the contrary, I’m trying to find out what you’re doing that’s different from standard stuff.