Skip to main content
Source baselineNereuscommit c820391dc1de·verified 2026-08-07·authority reader-facing-summary

Example: Pulsar with Object WAL sync

This example follows one ordinary Pulsar Entry in OBJECT_WAL_SYNC_OBJECT. The numbers are a worked scenario, not a benchmark or a promise of default deployment values.

Initial state

FactValue
Topicpersistent://tenant/ns/orders-partition-0
Projection incarnation1
StreamS-orders-1
Virtual ledgerV-7001
Committed end50
Commit version20
Trim offset0

The producer sends one complete Entry.

Append

  1. Pulsar performs protocol checks and calls ManagedLedger.addEntry.
  2. The facade wraps the complete bytes as AppendEntry(recordCount=1) for [50,51).
  3. Profile/capability admission verifies the Object WAL writer, reader, generation protocol, and runtime readiness.
  4. The stream lane obtains the current append session and expected offset 50.
  5. Object WAL writes the Entry into an immutable multi-stream object slice.
  6. Object PUT is verified by length, CRC, and metadata.
  7. Manifest and physical root are published; the append protection is established.
  8. The deterministic commit intent is written.
  9. Head CAS advances end 50 -> 51, commit version 20 -> 21, and records the commit ID.
  10. The sync profile confirms generation-0 index/readability.
  11. Nereus returns AppendResult(range=[50,51), generation=0).
  12. The facade returns Position(V-7001, 50).

The Position comes from projection plus logical offset. It does not expose the Object key or slice location.

Read

The consumer Position is mapped back to S-orders-1 offset 50. The resolver checks head and trim, selects generation 0 in COMMITTED, pins and revalidates the Object root/index, and reads the complete Entry bytes. Pulsar then decodes metadata, compression, and any batch index.

Higher generation

Materialization can publish a lossless NCP1 generation 1 for [0,100). After its index CAS is COMMITTED, a new read prefers generation 1 while the Position remains (V-7001,50). If generation 1 is unavailable, fallback remains within the same COMMITTED view and the generation-0 Object target is still selected if healthy.

When the old Object WAL can be deleted

The original Object is eligible only after generation 1 is healthy, a recovery checkpoint covers the old commit prefix, all reader/task/cursor protections drain, trim or replacement proof retires every live slice, and other streams in the same Object no longer reference it. The physical root then passes MARKED -> DELETING -> DELETED; object listing alone is not enough.

Source anchors