In this context, a runtime model is the conceptual/execution layer that decides what the system means and how it behaves at runtime.
A sync engine is the replication layer that decides how state moves between peers/devices.
Put differently:
Layer | Main question | Responsibility |
|---|---|---|
Runtime model | “What exists, what does it mean, and how is it used?” | Documents, links, facts, app semantics, subscriptions, queries, permissions, live state |
Sync engine | “How do peers converge on the same data?” | Replication, fetching, publishing, conflict handling, availability, peer-to-peer transport |
So a runtime model may say:
“There is a document, it has blocks, links, comments, metadata, capabilities, and live derived views.”
The sync engine says:
“Here is how those document changes, comments, blobs, and signatures get discovered, transferred, verified, and stored across nodes.”
A good boundary is:
Runtime model = product/application semantics
Sync engine = distributed systems plumbing
They overlap because the runtime needs synced data, and sync needs to know what data objects exist. But they should not be the same thing: the runtime should be able to express behavior without being tightly coupled to a particular transport or replication strategy.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime