4 State management with immutable data
So far we have seen how DO deals with requests that query information about the system, via generic functions that access the system data, represented as a hash map.
In this chapter and the following one, we illustrate how DO deals with mutations, i.e. 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.
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 DO, 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 forward the system state so that it refers to the version of the system data computed by the Calculation phase.
This distinction between Calculation and Commit phases allows us to reduce the part of our system that is stateful to its bare minimum. Only the code of the Commit phase is stateful, while the code in the Calculation phase of a mutation is stateless and made of generic functions similar to the code of a query.