Roadmap
Last updated: 2026-05-22
This page tracks the maturity level of distributed primitives across deployment modes and consolidates every Planned / not-yet-implemented feature into one auditable status table. It is the canonical single source of truth for “what works today vs what is planned.”
Distributed Primitives Maturity
| Primitive | Single-Node | Cluster (current) | Cluster (planned with Raft) |
|---|---|---|---|
| Distributed Locks | Stable — fencing tokens, TTL-based expiry | Partition-routing, no consensus — safe only when a single node owns the relevant partition | Raft-replicated via openraft — tracked internally |
| Pub/Sub Topics | Stable — fan-out, ephemeral messages | Partition-routed — no durable delivery guarantee across node failure | Durable log-backed delivery — planned |
| PN-Counters | Stable — CRDT merge | Stable — CRDT semantics tolerate concurrent increments | No change needed (CRDTs are naturally partition-tolerant) |
| Live Queries | Stable | Stable — subscriptions routed to partition owner | Cross-partition aggregation — planned |
| Cluster Consensus (Raft) | N/A — single-node needs no consensus | Not implemented — partition-routing only; no Raft leader election, no split-brain protection | Raft-replicated via openraft — planned; enables QUORUM/STRONG consistency, safe distributed locks, cluster mTLS |
Why This Matters: Split-Brain Risk in Partition-Routing Locks
Distributed locks in cluster mode currently use partition-routing without Raft consensus. They are safe for deployments where a single node owns the relevant partition, but provide weaker guarantees under split-brain. Raft-backed cluster locks are in development.
A split-brain occurs when a network partition causes two nodes to believe they are each the authoritative owner of the same partition. In that scenario, both nodes can independently grant locks for the same resource — violating mutual exclusion. The fencing token mechanism limits damage (stale writes are rejected by storage layers that check tokens), but does not prevent two concurrent lock-holders from being granted tokens by different nodes.
For single-node deployments (or deployments where partition ownership is stable and the network is reliable), this is not a practical concern. The lock implementation is correct and tested.
For multi-node deployments where split-brain is a real risk, wait for the Raft track before relying on distributed locks for critical mutual exclusion (payments, inventory deduplication, leader election).
Roadmap-Only Features
The features below are not implemented in the current Rust server. The guide pages linked here are design sketches — not reference documentation. They describe the intended API for future releases.
| Feature | Status | Planned design reference |
|---|---|---|
| Adaptive Indexing | Planned | /docs/guides/adaptive-indexing — TODO-174 |
| Cluster mTLS | Planned | Cluster traffic is plaintext TCP today; planned v3.0 |
| Custom Conflict Resolvers | Planned (v2.x) | User-defined merge functions; requires server-side WASM sandbox. SDK surface (client.getConflictResolvers().register/unregister/list) throws with a roadmap pointer pre-launch. Built-in CRDT merge logic + MergeRejection observability are unchanged. |
| Crash-safe shutdown drain + WAL recovery | Planned | TODO-339; write-behind can lose ~1s of buffered writes on unclean shutdown |
| Entry Processor | Planned (v2.x) | Server-side atomic read-modify-write via user-defined functions; requires WASM sandbox. SDK surface (client.executeOnKey/executeOnKeys) throws with a roadmap pointer pre-launch. |
| Hash/Navigable indexes | Planned | Distinct from tantivy full-text search (shipped); post-HN backlog |
| Indexing | Planned | /docs/guides/indexing — umbrella: Hash/Navigable + Adaptive Indexing |
| Interceptors | Planned | /docs/guides/interceptors — TODO-178 |
| RBAC role policies | Planned | Design sketch at /docs/guides/rbac; post-HN backlog |
| Scheduler — data-driven actions | Planned | TODO-317 |
| Scheduler — system cron | Planned | TODO-316 |
| TLS env-var config | Planned | Programmatic TlsConfig works today; env-var config is post-HN backlog |
| Webhooks | Planned | TODO-140 |
| Write Concern achievement reporting | Planned | achieved_level field always returns None today; post-HN backlog |
The Raft Track
Raft-backed cluster locks (via openraft) will provide:
- Persistent log: Lock acquisitions are written to a replicated log before being granted. No lock is granted unless a quorum of nodes acknowledges it.
- Leader election: A Raft leader owns each lock namespace. Split-brain is detected via quorum — the minority partition refuses to grant locks.
- Automatic failover: If the lock-owning leader fails, a new leader is elected and in-flight locks are resolved from the log.
This work is tracked internally. The current partition-routing implementation is a deliberate “ship the single-node path first, add consensus later” decision — not a design flaw.