Microservices - 72 resources

If you have a goods purchase service and a goods delivery service, you want to reserve the good (limited quantity) and reserve a time slot for transport (limited number of deliveries a day) before you charge the customer, and make the "commit".

And if you'd merge two separate companies into one uber-service, you've just created more problems than you've solved.

At least that case kept the same names, I think.

Starbucks is a good analogy (http://www.eaipatterns.com/ramblings/18_starbucks.html). If Starbucks were transactional, you would have to stand there at with the money on the counter and wait until your drink was finished, then exchange at the exact same time. Even the mental image is ridiculous.

In practice, it makes much more sense to allow the system to enter certain inconsistent states and then remediate them. Out of an ingredient? Refund the money. Can't pay? Pull the drink out of the queue, or just write it off. This can involve some cost, but less cost than than the throughput you'd lose by enforcing consistency.

For your specific example of a goods delivery service, most take-out restaurants fly in the face of these claims: you can pay the driver in cash when they arrive. They are willing to accept the risk that you made your order fraudulently, won't pay, etc. because it's still better for them to have your business.

If you reserved a time-slot or inventory for someone whose credit card is declined, so what? Just un-reserve it. It's not hard to UPDATE a row in a database. The system was in an inconsistent state for 10 seconds. Big whoop. (You might have turned down a legitimate customer, but only if they were consuming the last resource, and if demand is that high, another customer will buy the item.)

Notice that Ticketmater and most airlines will hold your seats (i.e. leave the system in an inconsistent state) for up to 15 minutes while you enter your card details. Hell, Ticketmaster can easily reverse a transaction at any point up until the moment your ticket is scanned at the door. So could an airline, and they often do.

The classic example of account balances isn't necessarily the case either - banks can INSERT records of individual transactions. Since addition is commutative, race conditions are irrelevant. Balances are then calculated nightly offline by playing back the transaction records. I guess that's a form of locking, but even if it weren't, the balance isn't the source of truth - the transactions are, and the balance can be recomputed.

Banks also don't hide the complexities of transaction processing. Your "current balance" is different from your "available balance" and your most recent transactions show as pending anyway.

You don't need transactions as often as you think you do.

You can emulate transactions to a certain extent by marking things are "incomplete" (which may result in things being invisible in some contexts) until they can be marked as complete across all services — an operation which cannot be atomic, but which can be "atomic enough" – or aborted. Versioning may be an option.

Sometimes you need "all or nothing" state management in a single microservice: You want to do "POST /object" multiple times and then cancel all of them on failure, for example. In one app we have a data import process which populates a microservice with a complex data model with many 1:n and n:m relationships. Instead of doing multiple REST calls (POST and so on), we build a "batch" object, which is essentially a JSON document. This batch lives in the microservice and acts like a persistent transaction. When we want to apply the changes, we tell the service to commit the batch. If the batch cannot be applied because it conflicts — ie., changes have been made by someone else since the batch started — the entire batch is dropped and the import starts from scratch. It's not terribly elegant or efficient, but it's fairly simple.