Skip to main content

Pulsar integration

Pulsar can carry the managed Shard Log and can receive ordinary or certified delayed destination traffic. The common lifecycle remains the same, while Pulsar-specific position, batching, resource guard, and delayed-delivery evidence stay explicit.

Pulsar as a Command source​

One physical Pulsar topic partition maps to one Delay Shard. Source order is based on the physical message position, including batch position when applicable. A source entry is acknowledged only after every accepted member through that entry has been durably applied or quarantined.

Recovery restores the Shard's applied source position, seeks the guarded source after that boundary, replays without acknowledgement, and crosses a fresh activation barrier before normal application resumes.

The Pulsar Resource Guard binds the configured physical topic and its creation identity to Producer creation, SEND, and guarded consumption. A same-name replacement cannot silently inherit the old Route or destination binding.

Ordinary managed delivery​

Ordinary managed Pulsar delivery follows the same timing rule as Kafka: actionAt = deliverAt, and the target send begins only after the trusted not-before boundary. This path works without delegating the remaining wait to Pulsar delayed delivery.

Certified delayed handoff​

A certified Profile may move network and storage work earlier. Nereus Delay sends before deliverAt at a calculated handoffAt, while Pulsar retains the message until its delayed-delivery timestamp.

This is allowed only when the target clock bound, Broker capability, resource guard, destination identity, credential binding, and required evidence remain certified. The timestamp includes the registered early-delivery safety bound so an ahead target clock cannot make the message visible before the business boundary.

The optimization changes where the final wait happens; it does not change the meaning of deliverAt, turn a queued Command into a published message, or create a universal exactly-once guarantee.

MANAGED and AUTO_FAST​

Managed handoff remains a server-side lifecycle with query, cancellation, rescheduling, retry, audit, and recovery boundaries. AUTO_FAST may instead choose a direct native Pulsar delivery before I/O. The native branch is not a managed message and never silently falls back after uncertainty.

Apache Pulsar's own messaging documentation describes native delayed message delivery. Nereus Delay adds the Route, lifecycle, evidence, recovery, and cross-Kafka/Pulsar management boundaries documented here.

Operational checklist​

  • Preserve physical topic and batch-aware Source Position semantics.
  • ACK only after the Shard apply is durably synchronized.
  • Treat delayed handoff as a certified Profile, not a default shortcut.
  • Monitor Broker clock and delayed-delivery capability drift separately from Worker time.
  • Keep native AUTO_FAST receipts separate from managed message queries.

See delivery time and action time and Managed and AUTO_FAST delivery.