Use cases

Tapstate is designed for operational data that loses value when it becomes stale. The patterns below describe the product model. The current preview implements one slice of it: MySQL and PostgreSQL capture into MongoDB-backed operational state.

Offload reads from a system of record

Customer need: Applications, dashboards, or agents should not add unpredictable query load to the production database.

tapstate model: Capture selected changes and maintain a read-oriented destination or materialized state for downstream consumers.

Verify before production: Initial-load consistency, CDC continuity, destination freshness, query behavior, source impact, and recovery after an interruption.

Migrate while the source remains active

Customer need: A replacement system must be prepared while the current system continues to accept writes.

tapstate model: Start with a bounded copy, continue with CDC, compare source and target, and cut over after the target is current.

Verify before production: Supported source version, log retention, full-load-to-CDC handoff, schema compatibility, update/delete keys, cutover procedure, and rollback plan.

Maintain a current customer or account view

Customer need: Customer, order, inventory, and entitlement data is fragmented across systems, while an application needs one current view.

tapstate model: Capture relevant changes and use nest to maintain a consumer-oriented document from related tables. The separately declared join transform remains outside the current runtime.

Verify before production: Join semantics, late and duplicate records, key changes, delete propagation, source-of-truth ownership, and reconciliation.

Supply operational context to AI systems

Customer need: Document retrieval and analytical stores can omit recent committed business state.

tapstate model: Expose governed operational state through a deterministic data contract while keeping the model and agent outside the data platform boundary.

Verify before production: Access control, data minimization, freshness requirements, auditability, failure behavior, and human authorization for actions.

Publish governed event feeds

Customer need: Multiple teams need a consistent stream or destination without independently reading the same production database.

tapstate model: Capture once, apply common policies, and deliver approved records through connector-defined targets.

Verify before production: Delivery semantics, replay, retention, serialization, schema evolution, consumer ownership, and cost under representative load.

Production-readiness questions

Assess every use case across four layers:

1. Connector support: Are the ID, role, mode, fields, permissions, and external-system preparation documented?
2. Resource validation: Does the installed tapstate version accept the resource shape and references?
3. Runtime behavior: Does the deployment connect, move data, checkpoint, recover, and handle schema changes correctly?
4. Operational evidence: Have correctness, latency, source impact, security, capacity, and failure handling been measured in the intended environment?

Start with the connector directory, then validate the selected path with representative data in the environment where it will run.