Distributed Synchronization Service

Documentation status: architecture — see Maturity and evidence.

Purpose

Distributed synchronization propagates semantic operations between replicas while preserving routing, journal progress, ordering/causal metadata, and acknowledgement state.

Core pipeline

local mutation
    -> synchronization operation
    -> durable journal
    -> routing policy
    -> causal/order metadata
    -> transport
    -> remote apply
    -> acknowledgement/checkpoint

Public design rules

• assign every replica a stable identity;
• synchronize operations rather than repeatedly shipping complete snapshots where incremental propagation is appropriate;
• keep routing policy outside domain mutation code;
• make remote application idempotent when duplicate delivery is possible;
• preserve causal/order metadata instead of relying only on wall-clock timestamps;
• bound in-memory queues and use durable journals when required;
• expose synchronization lag and checkpoint health.

Transport independence

Synchronization answers what changed, where it should go, in which causal context, and what has been acknowledged. The transport answers how the operation moves. A transport can therefore change without redefining domain mutation semantics if the required delivery guarantees are preserved.

Status

This page describes the current public programming model. Historical worker class names, FIFO tags, and module-class configuration are not public contracts.