Roadmap
Last updated: 2026-07-27
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.”
Stabilization Status
TopGun is in an active, public hardening program before we recommend unattended production use. The receipts are in the repository, not in marketing copy:
- Invariant catalog — every
durability/correctness invariant the system relies on, each mapped to the test that enforces
it. Invariants without an enforcing test are marked
NAKEDwith a tracking issue, visibly and on purpose; CI fails if that count grows silently. - Crash-recovery proof harness — a model-based generative test that drives write / flush / crash-at-any-point / recover / GC sequences against an independent reference model, with process-restart crossings inside each case. It re-detects every restart-boundary bug class we have found and fixed.
- A 72-hour endurance gate — the final exam (sustained churn + kill -9 loops with hard memory/disk/tombstone gates) runs once the remaining gates above are closed; we publish the criteria rather than the adjective “production-ready”.
Known, documented trade-offs (not hidden): the default batched WAL fsync policy acks writes
before fsync — an unclean crash can lose the last ~10 ms group-commit window server-side (the
originating client re-converges via its local op-log); set TOPGUN_WAL_FSYNC_POLICY=per_op for
acked-implies-durable. See the server configuration docs for the full list.
Single-node APIs are stable for development and self-hosted evaluation today.
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 |
| RBAC authorization | Stable — per-collection allow/deny policies enforced server-side (roles, deny-wins, predicate conditions). Policies are held in memory and are not yet durable across restart. | Enforced on every node; the policy store is not yet replicated across nodes | Raft-replicated policy store — 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 |
| 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.