Transactional correctness
Leases, epochs, routing, timestamps, and table metadata need committed transactional state, not eventual cache freshness.
MatrixKV
Strongly consistent transactional KV for critical platform state.
MatrixKV is the MatrixArk transactional KV foundation for routing metadata, table state, leases, transactions, timestamps, and ownership records where correctness and committed ordering matter more than cache-style freshness.
Product Advantages
Why MatrixKV over using a cache or generic KV for critical state?
Strong consistency boundary
MatrixKV gives metadata, ownership, and coordination records a strong consistency boundary that supports MatrixArk engines and managed operations.
Transactional KV role
It gives the platform a transactional KV layer while TemporalStore focuses on temporal serving and MatrixDB focuses on eventually consistent high-throughput KV serving and offline query.
Operational clarity
Separating strongly consistent transactional KV from hot serving data makes failure handling, ownership, and routing easier to reason about.
System Architecture
Client / proxy
Master
TSO
Partition server
Raft log
Storage engine
MatrixKV is the transactional, strong-consistency member of the MatrixArk family. It is not the default engine for high-cardinality temporal serving; it is the place to put metadata, leases, timestamps, ownership records, routing records, and transactional coordination.
Serving Workflow
- Client or platform component submits a metadata, lease, timestamp, or KV operation.
- Routing resolves the partition and current leader.
- Writes commit through the transactional consistency path before becoming platform-visible.
- Consumers use the committed state for routing, leases, and table metadata.
Scenario Architecture
Strong transactional KV for routing, leases, and table state.
Commit
Metadata writes pass through a transactional consistency path before becoming platform-visible state.
Coordinate
Masters, timestamp service, and partition servers maintain ownership and table metadata.
Protect
Epochs and committed records help reject stale writers and support controlled failover workflows.
Capabilities
The transactional KV layer under the Matrix engines.
Transactional metadata
Namespaces, tables, partitions, placement, schema, ownership, and routing records with strong consistency.
Leases and epochs
Protect primary ownership, failover decisions, and stale-writer rejection.
Timestamp service
Useful for transactional paths, ordering-sensitive writes, and system records.
Control-plane KV
Good fit for platform state that needs transactional correctness instead of cache semantics.
Transactional coordination
Supports coordination records for platform operations, metadata ownership, and routing workflows.
Platform complement
Works beside TemporalStore and MatrixDB instead of replacing their hot serving paths.
Comparison
| Alternative | Good at | MatrixKV difference |
|---|---|---|
| etcd | Kubernetes-style metadata and watch APIs | MatrixKV is a transactional KV foundation aligned with MatrixArk table, partition, and serving semantics. |
| FoundationDB | Strong transactional storage substrate | MatrixKV is narrower and intended as MatrixArk's transactional KV for metadata and control-plane records. |
| TiKV | Distributed transactional KV with MVCC | MatrixKV owns the platform strong-consistency role, while TemporalStore handles temporal serving. |
| MatrixDB | Eventually consistent multi-tenant serving and offline-query KV | MatrixKV is for transactional records with strong consistency; MatrixDB is for high-throughput KV where eventual consistency is acceptable. |
Where MatrixKV fits
MatrixKV is the product engine for transactional KV with strong consistency: metadata, routing, ownership, leases, timestamps, table state, and coordination records that should not behave like cache entries.
Talk to MatrixArk