Compensation: reverse-top-down
What the hell is reverse-top-down?
We have already seen that there is an “easy” way to introduce compensation in an existing architecture (the post can be found here, sorry it’s in Italian) and we have also seen that, generally, that requirement emerge due to some lacks of the original architecture design.
Suppose for a while that you know upfront that one of the non-functional requirements is compensation.
A sample?
Quite easy: in the environment you are working in data, even “related” data, are stored on different storage types and even in different locations, and that prevents the usage of distributed transactions (as you may already know I think that distributed transactions are evil). For the purpose of the post we can think to a model, made of Person(s) and Address(es) where Persons are stored in a relational database and the Addresses are accessed/stored using a remote service.
What happens when you want to create a new Person?
In this case we can imagine that the first step is to approach the creation of the Address that is the “related” entity that in case of failure can be abandoned.
The second step is to create, in a transaction if you like, the Person…if the creation fails the person does not exists and no one can find the orphaned address.
.m