statebox, an eventually consistent data model for Erlang (and Riak)
From the post:
When you choose an eventually consistent data store you’re prioritizing availability and partition tolerance over consistency, but this doesn’t mean your application has to be inconsistent. What it does mean is that you have to move your conflict resolution from writes to reads. Riak does almost all of the hard work for you [2], but if it’s not acceptable to discard some writes then you will have to set allow_mult to true on your bucket(s) and handle siblings [3] from your application. In some cases, this might be trivial. For example, if you have a set and only support adding to that set, then a merge operation is just the union of those two sets.
statebox is my solution to this problem. It bundles the value with repeatable operations [4] and provides a means to automatically resolve conflicts. Usage of statebox feels much more declarative than imperative. Instead of modifying the values yourself, you provide statebox with a list of operations and it will apply them to create a new statebox. This is necessary because it may apply this operation again at a later time when resolving a conflict between siblings on read.
I like that, “move conflict resolution from writes to reads.”
Sounds like where ISO/IEC 13250 points out two or more topic links maybe merged, and/or applications may process and/or render them as if they have been merged. (5.2.1 Topic Link Architectural Form)
Which fits your topic maps use case better? Consistency (one representative per subject) on write or read?