Transactional KV store
Leases, epochs, routing, timestamps, and metadata need committed state, not cache freshness or eventual consistency.
MatrixKV
Supporting transactional KV for trusted agent and product state.
TemporalStore can manage most LLM context by itself. MatrixDB covers larger Redis-compatible, multi-tenant database KV. MatrixKV is usually not required for context management; add it only when the product needs low-volume, high-importance transactional KV or strongly consistent data: permissions, document versions, workflow checkpoints, approvals, leases, routing decisions, timestamps, ownership, and committed actions.
When to involve MatrixKV
MatrixKV is a supporting engine, not a default context store. Most context management use cases should stay in TemporalStore, and larger database-style KV should go to MatrixDB. MatrixKV exists for the smaller, lower-volume records where stale reads, duplicate ownership, partial commits, or conflicting versions can make an agent, workflow, metadata path, or serving system unsafe.
Rule of thumb:
TemporalStore serves context. MatrixDB serves Redis-compatible online/offline/nearline KV.
MatrixKV protects the few records that must be strongly consistent before a prompt, action,
route, ownership transfer, or rollout decision is accepted.
Before the prompt
Check permissions, source versions, tenant policy, workflow locks, and approval status before context enters the model.
Before the action
Commit idempotency keys, leases, approvals, tool-call checkpoints, and ownership transfers before agents mutate product state.
After the action
Record committed outcome ids that TemporalStore can reference later for replay, audit, and stale-action blocking.
Keep it small
MatrixKV is for correctness-critical records, not high-volume memory, broad context retrieval, or generic prompt history.
Product Advantages
Why MatrixKV only for strong-consistency records?
Low volume, high importance
MatrixKV is for the small records where correctness matters more than raw serving volume.
Separate from MatrixDB
MatrixKV owns transactional and strongly consistent KV while MatrixDB owns Redis-compatible high-volume database KV.
Operational clarity
Separating strong consistency from hot serving data simplifies failover, ownership, and routing.
System Architecture
Application / API gateway
Control coordinator
Ordering service
Shard owner
Consensus commit log
Durable KV storage
MatrixKV is the transactional, strong-consistency KV database member of the MatrixArk family. It is not the default engine for LLM context management, and it is not MatrixDB's larger-scale Redis-compatible database KV. It is the KV database for lower-volume metadata, leases, timestamps, ownership records, routing records, transactional records, and coordination state that must be correct.
Serving Workflow
- Client or platform component submits a metadata, lease, timestamp, transaction, or KV database operation.
- Routing resolves the partition and current leader.
- Writes commit through the transactional consistency path before becoming database-visible.
- Consumers use the committed state for routing, leases, and table metadata.
Scenario Architecture
Committed workflow and metadata state for MatrixArk products.
Commit
Metadata, lease, timestamp, and KV writes pass through a transactional consistency path before becoming visible state.
Coordinate
Control coordinators, ordering services, and shard owners maintain ownership and table metadata.
Protect
Epochs and committed records help reject stale writers and support controlled failover workflows.
Capabilities
Low-volume transactional KV under the context platform.
Transactional database records
Namespaces, tables, partitions, placement, schema, ownership, routing records, and system KV records with very 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.
Object-storage metadata
Store bucket, object, version, manifest, placement, and lifecycle metadata that must commit before storage workers act.
Recommendation control state
Protect model rollout state, ranking experiment metadata, shard ownership, serving routes, and committed config for recommendation systems.
Feature and ML metadata
Keep feature definitions, model versions, training snapshots, online/offline cutover markers, and safety gates strongly consistent.
Strong database core
Good fit for platform state and KV records that need transactional correctness instead of context-serving or cache semantics.
Transactional coordination
Supports strongly consistent coordination records for platform operations, metadata ownership, routing workflows, and state transitions.
KV database complement
Works beside TemporalStore and Redis-compatible MatrixDB as the low-volume transactional KV database for state that must be strongly consistent.
Concrete use cases
MatrixKV protects the small decisions that cannot be wrong.
New customers can think of MatrixKV as the strongly consistent state layer for moments where a cache is too loose and a relational database is too general. The records are small, but the product impact is large: who owns an item, which model is live, which object version is visible, whether a workflow already committed, and which service is allowed to write.
Prevent double ownership
A game item, marketplace listing, coupon, or reward should not be claimed by two users. MatrixKV commits the ownership transfer, idempotency key, and rollback marker as one correct state.
Roll out models safely
Ads, search, and recommendation teams need one active ranker version, traffic split, rollback flag, and index-shard owner before serving traffic moves to a new model.
Show the right object version
An object store needs one visible version pointer after upload, multipart commit, lifecycle change, or repair. MatrixKV protects the small metadata record that decides what users read.
Cut over features correctly
Training and online serving must agree on feature definitions, snapshot ids, backfill epochs, and online/offline cutover markers before a feature becomes live.
Approve agent actions
LLM agents need auditable permission grants, tool-call commit ids, workflow checkpoints, and action approvals before a tool result changes product or customer state.
Fence stale workers
If a worker pauses and comes back late, it should not keep writing. MatrixKV stores leases, route epochs, shard ownership, and retry state so stale writers are rejected.
Comparison
| Alternative | Good at | MatrixKV difference |
|---|---|---|
| etcd-style metadata stores | Cluster metadata, service discovery, watches, and small coordination records | MatrixKV is a transactional KV database foundation aligned with MatrixArk table, partition, timestamp, routing, and serving semantics. |
| General transactional databases | SQL tables, joins, indexes, reports, constraints, and human-facing application records | MatrixKV is purpose-built for key-addressed transactional KV records: metadata, ownership, routing, timestamps, leases, epochs, idempotency, and platform state. |
| MatrixDB | Eventually consistent multi-tenant serving and offline-query KV database | MatrixKV is the Canonical truth and workflow KV; MatrixDB is the separate larger-scale KV database for high-throughput serving where eventual consistency is acceptable. |
| DynamoDB conditional writes | Managed conditional updates, item-level transactions, and application metadata | MatrixKV gives MatrixArk a dedicated strongly consistent coordination boundary for agent and infrastructure state rather than scattering correctness across application tables. |
Where MatrixKV fits
MatrixKV is the supporting low-volume transactional KV database for strong correctness: prevent double ownership, make model rollouts safe, show the right object version, cut over features correctly, approve agent actions, and fence stale workers with committed database state. It is usually not required for context management; use it only where a stale or conflicting answer is unacceptable.
Talk to MatrixArk