The problem
Why this system needed to exist.
Taking a snapshot and then starting a change stream creates a race: writes can occur between the two operations. Resume tokens can also be acknowledged too early, leaving a gap after a crash.
The destination needs more than a current copy. It must preserve ordered history, deletes, replay safety, and a clean current-state interface for downstream consumers.
The system
How the pieces work together.
The service captures an operation-time boundary, performs the initial snapshot, and continues from the corresponding MongoDB change stream. Snapshot rows and live events land in a durable PostgreSQL queue.
Resume state advances only after PostgreSQL accepts an event. A deterministic transform consumes the queue in MongoDB event order, writes SCD2 versions, closes prior versions, handles deletes, and exposes the current record through a view.