> Design the app so that no transaction state is kept in the web server, pass idempotent statements through the API with transactional identifiers rather than k

> Design the app so that no transaction state is kept in the web server, pass idempotent statements through the API with transactional identifiers rather than keep state. Let me see if I understand what your saying: 1) no transaction state is kept in the web server So if I'm a bank app, the data to populate the account history table and the form post data to transfer money are not held on to by the web server? You'd have to go out of your way to hold onto that data, unless you had some output caching block on the account history. Maybe my app is more complicated, and I have some type of long-running job, so I create a job class with all the job parameters, and stick it in Session, Redis, or plain App Memory Cache, while the client polls to see if the job is complete. You're saying don't hold onto the Job class, but just an identifier for the Job. 2) pass idempotent statements through the API with transactional identifiers rather than keep state How is this done? If the user wants to move $200 from account_a to account_b, twice, how is that handled? Which service generates the transaction identifiers?