MatrixArk Blogs
Product and architecture notes from building a matrix of online-state engines: TemporalStore for temporal decision features, MatrixDB for eventually consistent KV serving and offline query, and MatrixKV for strongly consistent transactional KV.
Fraud, ads, recommendation, and agent systems increasingly ask for fresh windows, filters, distinct counts, and sequences at request time. A generic cache can hold values, but it does not naturally explain how those values were computed, expired, filtered, replayed, or kept consistent with event history.
One engine should not pretend to be ideal for every workload. Temporal decision features, eventually consistent serving-query KV, and strongly consistent transactional KV need different architectures. MatrixArk keeps the engines separate while sharing deployment, observability, SDK conventions, and operations.
The product has to be easy to run before it can be easy to buy. That means clear node roles, package boundaries, health checks, public metrics, cache volumes, rollback plans, and a test topology that can be recreated without hand tuning.
Vector databases retrieve semantic neighbors. Temporal serving stores the structured state around those interactions: session timelines, recent tool use, policy counters, user preferences, and freshness-sensitive context that prompt builders need.