As I watch computer systems become ever more complicated by the day, I get an unnerving suspicion the idea of data consistency is a temporary anomaly of our time, given that our current systems are just small enough to make it possible yet we’re still naive enough to make it seem desirable.
At one point I was leisurely looking into object design from a domain-driven design perspective11 Effective Aggregate Design, Part II: Making Aggregates Work Together; Vernon; 2011. Available online. . This bit was particularly thought-provoking:
Thus, if executing a command on one aggregate instance requires that additional business rules execute on one or more other aggregates, use eventual consistency. Accepting that all aggregate instances in a large-scale, high-traffic enterprise are never completely consistent helps us accept that eventual consistency also makes sense in the smaller scale where just a few instances are involved.
Ask the domain experts if they could tolerate some time delay between the modification of one instance and the others involved. Domain experts are sometimes far more comfortable with the idea of delayed consistency than are developers. They are aware of realistic delays that occur all the time in their business, whereas developers are usually indoctrinated with an atomic change mentality. Domain experts often remember the days prior to computer automation of their business operations, when various kinds of delays occurred all the time and consistency was never immediate. Thus, domain experts are often willing to allow for reasonable delays—a generous number of seconds, minutes, hours, or even days—before consistency occurs.