State engine lifecycle
We saw in the previous examples how to produce a snapshot, and how to produce a delta. You may have gathered that the state engine has two lifecycle stages.
- Adding objects to create a data state
- Producing blobs
To get the full benefit of Zeno, we can create a process whose sole purpose in life is to continuously recreate the entire data state, then produce blobs to bring a set of servers up to date:
Each execution of this loop is called a cycle, and the data which is added to the state engine is called a data state. A delta blob is a transition from the previous state to the current state. On each cycle (except for the very first), we should produce a delta file. Sometimes, we should produce a snapshot file so that any new machine which needs the data we produce can bootstrap itself:
Note the use of a version number in the above example. When we set a version on the state engine, any client which consumes a blob produced by that state engine will also have the same version on their state engine.
We always need to be careful, when applying a delta, that we are following a transition from the appropriate data state. We can take advantage of this data state version to ensure that this always remains true. Netflix, for example, always stores its files in Amazon S3 such that a delta file’s name is identical to the version number to which it should be applied. In this way, blob consumers always knows where to look for their next delta — they just call stateEngine.getLatestVersion().
Check out the next page to learn about the blob consumer lifecycle.