Producing a Delta

In our previous example, we added all of the known objects to our state engine, and then used it to serialize a blob snapshot. This snapshot can be read by any machine to duplicate in memory all of the objects which were added to the state engine.

However, one of the most powerful aspects of the Zeno framework is the ability to not only propagate data to additional machines, but to keep a data set up to date.

Continuing our example from the previous page, after we have written our blob file, we need to inform the state engine that we are ready to once again add all of the objects we know about:

Then, we recreate our data from the sources of truth. Because some time has passed, we suspect this data will be slightly different than the last time we did this:

Once we have added all of the objects again, we need to tell the state engine that we are ready to write more blob files:

Now, we can produce a delta blob:

If this delta is applied to a state engine on some machine which loaded the snapshot we produced in the previous example, then that data will be brought up to date.

Let’s recap our example, without the noisy comments:

The delta must be consumed by a state engine which has previously loaded the snapshot we produced in the last example. Each time we add all of the objects to our state engine, we call that a cycle. All of the instances we add during that cycle comprise a data state. A delta should only ever be applied to a state engine that holds the state from the previous cycle.

Continue on to the next page State Engine Lifecycle to learn how to fit these pieces together into a process which continuously updates.