by Pat Helland
Gray and Reuter define consistency as: “A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.”
Loosely translated, you should be happy with yourself. In your own opinion, you should be sane.
Through the years, this most ill defined property of the ACID transaction has been conflated with isolation and interpreted through the prism of read/write updates to an apparently centralized record oriented database. This suits systems developers that need a narrow definition to feel they can accomplish something. Unfortunately, it leaves many real world problems in the dust.
In this talk, we will explore the models of consistency and the facades of reality used in practical systems.
In order to operate 24/7 an application must embrace constant change and failure. This kind of resiliency is achievable through the application of reactive design principles. Learn the theory via real-world examples at Netflix along with some lessons learned the hard way in production. Topics of interest will include service-oriented architectures (microservices), cloud computing, where to put application state, hot deployments, bulk heading, circuit breakers, degrading gracefully, operational tooling and how application architecture affects resilience.
18th–21st November 2014