Is this problem covered?
* Try Again Later: queue failed parts of the transaction for retry, moving towards eventual consistency
* Abort the Entire Operation: On failure issue a compensating transaction to roll back the previous successes
* Distributed Transaction: have some overall governing transaction manager process that orchestrates consistency (e.g. duplicate the transaction process of your monlithic data store up in the application layer). You could do a two-phase commit where each participant in the distributed transaction tells the transaction manager whether it thinks its local transaction can go ahead. "A single no vote is enough for the transaction manager to send out a rollback to all parties."
For each of these approaches there are issues, obviously, and to his credit he's pretty even-handed about them. He also says:
"If you do encounter state that really, really wants to be kept consistent, do everything you can to avoid splitting it up in the first place. Try really hard. If you really need to go ahead with the split, think about moving from a purely technical view of the process (e.g., a database transaction) and actually create a concrete concept to represent the transaction itself."
He gives an example of a domain model for a retail company of an order-in-process: instead of attempting to capture a user's order as a single database transaction, model the concept of an order flow of through fulfillment, shipping, marketing, accounting, etc.
If these N things were just database writes to the same DB, transactions would save you, as you could just rollback. Without that, the answer has to be handled in code -- do you reverse the previous changes (if possible) by sending delete events, or leave the system in some sort of half-baked state and rectify things later via some other process? (I'm interested in hearing of other options...)
It's all very neat, though I'm doing a bad job explaining. Search for Amazon architectural presentations and hopefully you can find it. It may have been on James Hamilton's blog, maybe.
[1] - http://en.wikipedia.org/wiki/Consensus_%28computer_science%2... [2]- http://en.wikipedia.org/wiki/Paxos_(computer_science)
You know, if it's free, you're the product and all that yadda yadda.
By posting the direct DL link here, you are discouraging similar free offers in the future. If I were you and I appreciated free offers, I would consider editing my post.
I have given O'Reilly my email before, but the content is absolute crap. They are spamming me even though I have cancel the subscription 3 times, hence direct link may bring them more marketing value than bunch of spam-only emails with fake names and phones numbers.
This is exactly why the direct link should be shared. I'd bet that most HN users aren't interested in "future marketing."
It's all free.
If you're interested in more microservices stuff, here's the link to the first one. Fair warning, though: this isn't professionally produced or slick. It's just some schmuck (me) programming.
One thing I've found is that infrastructure stuff abounds for Java-based projects, doing much work for the message bus, metrics, and logging. But I find much less available for .Net, particularly for the latter two. Maybe you'll find some stuff that'll help me.
As an Agile coach, what I find interesting is conveying the philosophy of the work. I am nowhere near being a code ninja any more, but the way you think about writing the application is the most important part of doing the work.
But who knows? We'll see.
EDIT: To be a little clearer, message bus? You sure you need a full-bore bus? Make it work with simple files. Take a look at your volume. If you code it correctly from the start, adding on new stuff is easy. If you start with lots of frameworks and such, you can get caught up in complexities that are orthogonal to your mission. One of the beauties of going full functional is that it makes you focus on whether the dang thing is working or not. In an OO environment, many times you get lost in the "wiring" of the construction, making sure you implement the correct interfaces, paying attention to Demeter's Law and the rest. The end of the week comes and all you've got is forty thousand lines of code and 7 new dlls in your build.
Still free though. I snatched a copy.
(No side-interest here, just found it confusing that the page mentioned "hardcopy expected to be published in May")
