Why Nereus Delay?
Applications often need a message to become eligible for a destination consumer no earlier than a business time. Kafka and Pulsar expose different producer, partition, delayed-delivery, and acknowledgement semantics. Nereus Delay provides a durable scheduling boundary above those systems while keeping the destination-specific evidence visible.
V1 goals
- Accept immutable Schedule, Cancel, Reschedule, Payload Commit, and control commands through a durable Command Topic.
- Apply the complete Shard Log in source order to one RocksDB database per Delay Shard.
- Schedule destination work with persistent Destination Lanes, bounded fairness, retry policy, and lane-local failure isolation.
- Make query, cancellation, rescheduling, recovery, retention, and cleanup depend on explicit durable state.
- Avoid early delivery when the scheduler's trusted time is uncertain.
The central boundary
deliverAt is a not-before visibility boundary. It is not a promise that publishing starts exactly at that instant or that a consumer receives the message at that instant. Backlog, target throttling, retries, Broker dispatch, and consumer availability can make delivery later.
The service also distinguishes a Command being queued from the Delay Shard authoritatively applying that Command. A Broker acknowledgement alone cannot prove that a delayed message exists.
What this product does not promise
Nereus Delay does not claim universal exactly-once delivery, global ordering, arbitrary per-message destination configuration, online migration between destinations, or automatic production approval for every deployment environment. See V1 non-goals and current project status.