title: Transactions across REST microservices?
body: <p>Let's say we have a User, Wallet REST microservices and an API gateway that glues things together. When Bob registers on our website, our API gateway needs to create a user through the User microservice and a wallet through the Wallet microservice. </p>
  
  <p>Now here are a few scenarios where things could go wrong:</p>
  
  <ul>
  <li><p>User Bob creation fails: that's OK, we just return an error message to the Bob. We're using SQL transactions so no one ever saw Bob in the system. Everything's good :)</p></li>
  <li><p>User Bob is created but before our Wallet can be created, our API gateway hard crashes. We now have a User with no wallet (inconsistent data).</p></li>
  <li><p>User Bob is created and as we are creating the Wallet, the HTTP connection drops. The wallet creation might have succeeded or it might have not.</p></li>
  </ul>
  
  <p>What solutions are available to prevent this kind of data inconsistency from happening? Are there patterns that allow transactions to span multiple REST requests? I've read the Wikipedia page on <a href="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">Two-phase commit</a> which seems to touch on this issue but I'm not sure how to apply it in practice. This <a href="http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf">Atomic Distributed Transactions: a RESTful design</a> paper also seems interesting although I haven't read it yet.</p>
  
  <p>Alternatively, I know REST might just not be suited for this use case. Would perhaps the correct way to handle this situation to drop REST entirely and use a different communication protocol like a message queue system? Or should I enforce consistency in my application code (for example, by having a background job that detects inconsistencies and fixes them or by having a "state" attribute on my User model with "creating", "created" values, etc.)?</p>