4 State management

 

Time travel

This chapter covers

  • A multi-version approach to state management
  • The calculation phase of a mutation
  • The commit phase of a mutation
  • Keeping a history of previous state versions

So far, we have seen how DOP handles queries via generic functions that access system data, which is represented as a hash map. In this chapter, we illustrate how DOP deals with mutations (requests that change the system state). Instead of updating the state in place, we maintain multiple versions of the system data. At a specific point in time, the system state refers to a specific version of the system data. This chapter is a deep dive in the third principle of DOP.

Principle #3

Data is immutable.

The maintenance of multiple versions of the system data requires the data to be immutable. This is made efficient both in terms of computation and memory via a technique called structural sharing, where parts of the data that are common between two versions are shared instead of being copied. In DOP, a mutation is split into two distinct phases:

  • In the calculation phase, we compute the next version of the system data.
  • In the commit phase, we move the system state forward so that it refers to the version of the system data computed by the calculation phase.

4.1 Multiple versions of the system data

4.2 Structural sharing

4.3 Implementing structural sharing

4.4 Data safety

4.5 The commit phase of a mutation

4.6 Ensuring system state integrity

4.7 Restoring previous states

Summary

sitemap