Schedule
Prepare an immutable command and enqueue it to the configured Kafka or Pulsar Command Topic.
V1 in development
Nereus Delay
Durable delayed-message scheduling across Kafka and Pulsar destinations.
Managed scheduling, cancellation and rescheduling with durable shard state, destination isolation, explicit uncertainty, and checkpoint-based recovery.
deliverAt
actionAt
Kafka · Pulsar
What it does
Scheduling is a durable state machine, not a timer.
Nereus Delay separates command ordering, shard application, destination admission, and producer evidence so each result has a concrete meaning during retries and recovery.
Cancel and reschedule
Managed messages retain query, cancellation, and rescheduling boundaries before publish admission.
Payload commit
Large payloads use reserve, upload, attest, and commit as separate durable stages.
Query
Queued and applied outcomes remain distinct; a query barrier determines when an applied answer is conclusive.
End-to-end flow
One Delay Shard owns one ordered recovery unit.
The V1 identity is fixed: one Ingress Route partition is one Shard Log, one Delay Shard, one RocksDB instance, and one ownership/recovery unit. Oxia coordinates configuration, placement, leases, and checkpoint catalog; Object Store holds checkpoints and large payloads.
SDK
Command Topic
Shard Log
Shard Log
Delay Shard
RocksDB
RocksDB
Scheduler
Destination Lane
Destination Lane
Kafka / Pulsar
destination
destination
Timing semantics
deliverAt is a not-before boundary.
It is the earliest instant at which a destination consumer may become eligible to see the message. It is not the time publishing starts and it is not an exact-time visibility guarantee.
actionAt- The earliest time Nereus Delay may start the destination action.
- Trusted UTC interval
- Clock uncertainty can delay a decision, but cannot authorize an early publish or premature expiration.
expireAt- A durable Publish Admission boundary; source lag does not rewrite an already valid admission into rejection.
Delivery boundaries
Every outcome keeps its evidence level.
Queued
The ingress Broker durably accepted a Command. It does not mean that the Delay Shard applied the requested operation.
Applied
The Delay Shard durably recorded an authoritative applied or rejected result in its ordered state machine.
Published
A destination adapter has durable evidence for the target append or handoff inside its configured capability.
Uncertain
The system cannot prove whether a producer-side operation became durable; recovery keeps the duplicate-risk boundary explicit.
The baseline delivery capability is bounded at-least-once. A destination may observe a duplicate; Nereus Delay does not claim universal exactly-once.
Isolation and recovery
Failure in one destination lane should not stop unrelated work.
Destination Lane isolation
Lane state carries destination, tenancy, ordering, capacity, retry, circuit, fairness, and due-lag boundaries. It is not an ownership or checkpoint unit.
Checkpoint and Recovery Floor
A published checkpoint belongs to a bounded Recovery Set. The Recovery Floor protects state and external objects required by every permitted recovery image.
Replay before readiness
Restore, verify identity and integrity, replay the Shard Log, and cross the activation barrier before command application resumes. Lane readiness remains a separate gate.
Current status
V1 in development
Core protocol, deterministic state-machine, local RocksDB, scheduler, and typed evidence boundaries are being built in testable layers. Release readiness still depends on concrete broker adapters, authenticated external evidence, Oxia authority, real-service integration, chaos, benchmark, and upgrade evidence.
- Source baseline
9281890f4277- Spec revision
- V1-FROZEN-2026-08-01
- Verified
- 2026-08-07
- Release posture
- Not release-ready
Documentation
Follow the V1 reading path.
Start with the architecture and time model, then move to commands, scheduling, lane isolation, recovery, and the current implementation status.