A useful Customer 360 is a maintained operational model, not a request-time integration workflow. If an application must call CRM, billing, orders, loyalty, and support for every customer request, it does not have a Customer 360. It has a distributed join whose latency and availability are determined by its slowest source.
Why runtime composition fails
Each system owns legitimate local facts. CRM may own profile data, billing the payment position, and fulfillment the shipment status. The problem appears when a consumer needs the combined state. Runtime composition multiplies network calls, credentials, schemas, retry policies, and failure modes. It also pushes read load onto systems designed to process transactions rather than serve an expanding set of digital applications.
Caching individual API responses helps latency but does not solve identity, cross-source ordering, conflicting values, or deletion. The same customer may use an account number in billing, a CRM ID in service, and an email address in loyalty. A cache preserves those inconsistencies faster.
Maintain the view before the request
The stronger design is a source-to-serve state path:
- Establish a baseline from each participating source.
- Capture committed changes continuously where the connector supports it.
- Resolve each source key to a durable customer identity.
- Normalize and combine source-oriented records into a consumer-oriented entity.
- Materialize the current entity under a stable key.
- Let applications read that maintained state through a normal database driver or API.
The read path becomes simple because the hard integration work happens continuously. A request retrieves one customer document or record instead of orchestrating five production calls.
Define authority by field
“Golden record” is often too vague for operational use. Authority should be explicit at field or domain level. CRM can own the preferred name while billing owns balance and payment status. A support system can own the open-case state without being allowed to overwrite identity data.
The materialized entity should also retain enough provenance to answer which source supplied a value, when that source changed it, and when the state layer applied it. This makes conflicts diagnosable instead of hiding them behind a merged JSON response.
Treat freshness as a contract
Freshness is not one timestamp. A Customer 360 may be current for profile data and stale for payments. Operators need source progress, pipeline checkpoints, target acknowledgements, and per-domain lag. Applications should know which fields are safe to act on when a source is delayed.
Design the entity around decisions
The entity should reflect repeated operational decisions, not every attribute available in every source. A customer-service workflow may need verified identity, active accounts, payment standing, open orders, entitlements, and unresolved cases. Marketing history, raw clickstream events, and years of invoices can remain in analytical systems unless the workflow needs them.
Keep independently changing domains separable. Embedding hundreds of orders inside one customer document creates write contention and large updates. A better model often uses a compact customer aggregate with references to order and case entities. The correct boundary depends on read frequency, update frequency, and the consistency required inside one response.
Derived fields need written definitions. If customer_at_risk depends on overdue balance and an open support escalation, specify the source fields, rule version, and behavior when one source is stale. Otherwise, the derived label becomes impossible to explain during an incident.
Plan baseline and cutover
A production rollout needs more than enabling CDC. Establish a consistent initial baseline, retain changes created during the copy, catch up from a known source position, and validate the assembled entities before moving traffic. Compare a controlled sample against direct source reads, including customers with merges, deleted accounts, missing keys, and recent updates.
Move consumers gradually. Start with read-only workflows whose tolerance for asynchronous state is understood. Track the reduction in source queries and the state path’s commit-to-serve latency. Keep a documented fallback for authoritative checks rather than silently routing every request back to all sources.
Evaluate success with operational evidence
Useful measures include production reads avoided, p95 and p99 API latency, entity freshness by domain, reconciliation differences, recovery time, and the number of consumers reusing the same model. A large synchronized row count is not evidence that the Customer 360 is correct or useful. The proof is that real workflows can rely on it under normal operation and during a source or pipeline interruption.
Where Tapstate fits
Tapstate is built for the maintained-state pattern described above. Its Capture → Transform → Serve path continuously captures changes from systems of record, reshapes them into application-oriented entities, and maintains those entities as reusable operational state. Applications, APIs, automation, and agents can read from that maintained state instead of rebuilding the same cross-system join on every request.
The systems of record remain authoritative for transactions and domain rules. Tapstate’s role is to keep the downstream operational representation current and usable, not to decide which customer identifier is canonical or which system owns a particular business field. Those decisions remain with the organization and are reflected in the model Tapstate maintains.
The practical test is simple: if every consumer still has to reconstruct the customer from CRM, billing, orders, and support, the integration problem has only been moved around. A reusable Customer 360 exists when that combined state is maintained once and can serve many consumers without sending every request back through the source systems.
———————————————————————
Build it with your own data
See how Tapstate can turn continuously changing source data into maintained operational state for applications and APIs.
