Chapter 8. Delimited consistency

 

One possible definition of a distributed system is a system whose parts can fail independently.[1] Reactive design is distributed by its very nature: you want to model components that are isolated from each other and interact only via location-transparent message passing in order to create a resilient supervisor hierarchy. This means the resulting application layout will suffer the consequences of being distributed. In a stateless system, the consequences relate primarily to failure handling, and recovery is handled as described in the previous chapter. When the system has state, it is not so simple. Even when each part of the system works perfectly, time is a factor. As you learned in chapter 2, a consequence of being distributed is that strong consistency cannot be guaranteed. In this chapter, you will learn about delimited consistency, which is the next-best alternative.

1A more humorous one by Leslie Lamport is as follows: “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” (Email message, May 28, 1987, http://research.microsoft.com/en-us/um/people/lamport/pubs/distributed-system.txt.)

8.1. Encapsulated modules to the rescue

8.2. Grouping data and behavior according to transaction boundaries

8.3. Modeling workflows across transactional boundaries

8.4. Unit of failure = unit of consistency

8.5. Segregating responsibilities

8.6. Persisting isolated scopes of consistency

8.7. Summary

sitemap