Distribution Server State Management

The pattern require synchronize state between server instances. Then gstate should persist against database which able notify changes or an event queue.

1. A server instance persist changes to database or event queue.
2. A second server instance is notified and use state.set to update its own state.

GState's persistence interface have sync API to simplified distribution state management pattern.

The sample use couchdb adapter which able notify changes.

const GState = require("../src/index");
const adapter = require("./couchdb.adapter");
const persist = require("../src/persist")(
    adapter,
    "http://localhost:5984/gstate"
);

const state2 = new GState();
state2.watch(
    {
        items: {
            _: "$key"
        }
    },
    data => console.log(data)
);
persist.sync(state2); // sync state2 

const state1 = new GState();
setInterval(() => {
    persist.insert(state1, ["items", new Date().getTime()], { text: "aa" });
}, 2000);

It seems your instance's state is stale?

It is true that possible state2's data could be out of date before receive a change from state1. The issue could make your data's inconsistent:

1. State1 received remove an user.
2. State1 verify the user's object is existed and call persist.remove(user_obj).
3. Database commit the change and notify state2.
4. Before state2 received the changes, it handle a update request against same user object.
5. State2 verify the user's object is existed and call persist.update(user_obj).
6. But the object already removed by state1.

In fact, the issue could happened in stateless server pattern too.

1. Instance1 received remove an user.
2. Instance1 call query database to get the object and perform remove action.
3. Instance2 received update same user.
4. Instance2 call query database to get the object and perform update action. It is possible query action happen before above remove action
5. The database automatically detect the second update action is fail because the object not existed.

So it is critical that gstate's adapter should be handle stale data issues. It should report the second persist.update failed then state2 not update invalid state.

How about data consistent and atomic updates?

To keep simple, gstate only implement very simple persistence interface. Data consistent, atomic updates, and distribution state synchronization hide inside adapter code.

It is depend on adapter backends and custom implementation to achieve those requirements.