RFC 1449 step 6 (demand-gated): split Store into EventStore + SubscriptionStore

[Rotorsoft]

Step 6 of RFC 1449. Demand-gated — do not build speculatively. Blocked by step 5.

Why this is last, not first

The port boundary was never the constraint; the pull model was. Once claim reads only its own tables, Store divides cleanly:

• EventStore — commit, query, query_stats, scan/restore, forget_pii, notify
• SubscriptionStore — subscribe, claim, ack, block, unblock, defer, prioritize, reset, query_streams

correlate is the only component holding both, and it is a pipeline, not a distributed transaction: read from the event store at a checkpoint, write to the subscription store idempotently. streams.at and correlated remain event-store ids, but the subscription store only ever compares them — the opaque-monotonic-token property Kafka offsets and Axon tracking tokens have.

What it costs

A second port, a second TCK, a second capability matrix, and an untested adapter × adapter combinatorial surface. It buys a deployment option and no performance that step 5 has not already delivered.

truncate remains the one genuinely cross-store operation and needs a resumable two-phase protocol — tractable, since close is low-cadence and #1389 already made an interrupted close resumable.

The gate

Open this only for a workload where the events half is the constraint in a way the subscription half is not — archival events on object storage with leases in Postgres is the shape that would qualify. Re-run store-split-claim.bench.mjs against the mark (not the old joined baseline) so the decision is made on current numbers.

Absent that workload, the correct outcome for this ticket is closed as not needed, which is a successful result for the milestone rather than a failure.

[Rotorsoft]

Deferred to 2.0, and probably superseded. The deployment flexibility this step was meant to buy is available without splitting the port, so the split no longer justifies its cost inside 1.x.

Why the split is no longer the way to get this

A hybrid adapter implements the existing single Store interface and routes internally: the event-log half (commit, query, query_stats, scan/restore, forget_pii, notify) to one system, the subscription half (subscribe, claim, ack, block, unblock, defer, prioritize, reset, query_streams) to another. Callers see one Store; the seam is an implementation detail.

#1488 is what unlocked this. While claim probed the event log, a hybrid would have needed a cross-store read on the hottest path in the framework — which is exactly the join RFC 1449 set out to remove, reintroduced at the adapter boundary. Now that eligibility is at < correlated_at on the subscription row, every method belongs cleanly to one half or the other.

The precedent already exists in-tree: @rotorsoft/act-notify's withBroker(store, broker) decorates a durable Store and redirects one concern (wakeups) to another system, TCK-proven over PostgresStore. A hybrid store is the same shape with a different seam.

What the split would still cost

Two ports, two TCKs, an adapter × adapter conformance matrix, and a rename of a charter-covered surface — a breaking change requiring a BREAKING CHANGE: footer and a migration note. RFC 1449 already judged it as buying "no performance the mark does not already deliver". With the hybrid path open, it also buys no deployment flexibility.

What survives for 2.0 to decide

If a hybrid adapter ships and the internal seam turns out to want expressing in the type system — because implementors keep writing the same delegation boilerplate, or because truncate's two-phase protocol proves genuinely awkward behind one interface — that is the evidence that reopens this. Absent that, the single interface stays.

truncate remains the one genuinely cross-store operation either way, and #1389 already made an interrupted close resumable, so a hybrid needs a two-phase protocol there regardless of whether the port is split.

Follow-up on which system pairs well with a Postgres event log: see the note on #1510.