Skip to content

[WIP] Building a Sync Engine

HyperDB does not have a built-in sync layer yet, but it already gives you the primitives a sync engine needs: transactional actions, lifecycle hooks that run inside the committing transaction, traits for tagging the origin of a write, and the ability to wire multiple databases together.

We plan to release sync primitives soon. They will unlock:

  1. Client and server change tracking
  2. Sending and applying changes between clients and servers
  3. Cross-tab syncing

The design will work like this:

  1. A change-tracking table that records what changed and when.
  2. Lifecycle hooks that append change records on every mutation.
  3. Merge actions that apply remote changesets with last-write-wins semantics.
  4. A two-tier runtime: an in-memory tier for the UI, a persistent tier for durability, plus the glue that hydrates, persists, and syncs.
  5. Each tab broadcasts changes so other tabs can apply them.

Because actions can run on the server too, the server can act as another peer: it applies incoming changes, runs the same merge logic, and sends new changes back to clients.

I plan to port this from the current Will Be Done implementation. You can see how it works in the store loader, shared change-tracking slice, and API startup code:

  1. Store loader
  2. Shared change-tracking slice
  3. API startup code