Data Consistency, Integration, Migration, and AI Safety Patterns

Goal

Show how to select patterns when data truth or business meaning must cross system, ownership, time, or automation boundaries.

The earlier sections began with familiar quality concerns: failure, load, access, governance, and operations. This final concern group is broader because it often combines all of them. The durable idea is:

When meaning crosses a boundary, the architecture must preserve truth, intent, control, and evidence even when the two sides change or fail independently.

The Short Version

Data consistency, integration, migration, and AI safety are not one pattern family. They are four views of a boundary-crossing problem:

• Consistency asks which state is authoritative and when other views may differ.

• Integration asks how meaning moves between independently owned systems.

• Migration asks how authority and traffic move while the business keeps running.

• AI safety asks what an adaptive component may see, say, and do, and how its behavior is evaluated.

Meaning or state at a boundary
  -> identify authority and contract
  -> choose movement and timing
  -> control duplicates, delay, change, and partial failure
  -> authorize high-impact actions
  -> reconcile and preserve evidence

The best review question is not "which integration technology should we use?" It is "what truth or intent crosses this boundary, what can go wrong while it moves, and how will both sides know what happened?"

One Concern Map, Four Lenses

These directions overlap. An outbox supports integration by connecting a state change to reliable message publication. Reconciliation supports both distributed consistency and migration validation. Identity and policy controls from the previous section are essential when an AI agent calls a business tool.

Data Consistency: Name the Truth and the Allowed Delay

Distributed systems rarely make every copy current at the same moment. The architecture needs a more useful promise:

• Which component may decide the authoritative state?

• Which decisions require immediate confirmation?

• Which views may be stale, and for how long?

• What happens when the same request or message arrives twice?

• How are conflicts, partial completion, and missing updates repaired?

Use one owner for each business invariant where possible. For example, an order responsibility owns whether an order was accepted; a payment responsibility owns its payment state; an inventory responsibility owns stock allocation. Other systems may hold views of those facts, but copying data should not silently transfer authority.

Idempotency protects repeated intent. Optimistic concurrency detects conflicting updates. An outbox-style pattern records a state change and the fact to publish within one local transaction, then publishes asynchronously. A saga or compensating workflow coordinates a business process across separate owners without pretending there is one global transaction. Reconciliation compares expected and observed state and routes differences to repair.

The trade-off is often between immediate global agreement and availability, autonomy, latency, or operating complexity. State the business consequence of temporary difference rather than using "eventual consistency" as a blanket excuse.

Integration: Match the Mechanism to the Meaning

Different messages carry different intent:

Adapters and anti-corruption layers keep an external or legacy model from leaking into every internal component. Version contracts for compatible change, test consumers, and retain enough history to replay when replay is a real recovery requirement.

Migration: Move Authority, Not Only Data

A migration changes where requests go, where truth is written, how old and new systems coexist, and who operates each path. A safe sequence is often:

flowchart LR
    A["Observe current behavior"] --> B["Introduce stable boundary"]
    B --> C["Backfill and validate data"]
    C --> D["Mirror or compare safely"]
    D --> E["Move a bounded traffic slice"]
    E --> F["Cut over authority"]
    F --> G["Reconcile and retire old path"]

Not every migration requires every stage. The principle is to separate reversible preparation from the moment authority changes.

A strangler pattern routes selected capabilities to a new implementation while the old system continues to serve the rest. An anti-corruption layer translates between models. Expand-and-contract allows a contract or schema to support old and new consumers during transition. Backfill and change capture can prepare data, but the team must define which side accepts writes and how lag or failure is repaired.

Dual writing from application code is especially risky because one write can succeed while the other fails. If temporary dual propagation is unavoidable, make one side authoritative and build durable replication, comparison, and repair around it. Do not declare migration complete until dependencies, operational ownership, rollback conditions, and retirement work are resolved.

AI Safety: Control Capability, Not Only Output Text

AI safety begins with the job the system is permitted to perform. A model that drafts a product description has a different risk shape from an agent that can issue refunds, change inventory, or expose customer data.

Use patterns that constrain the full action path:

• authorize retrieval using the user's and workload's context;

• filter or structure retrieved data so sensitive content is not included by accident;

• expose a small registry of scoped tools rather than arbitrary system access;

• validate tool inputs and business invariants outside the model;

• require human approval for high-impact or irreversible actions;

• isolate code or tool execution where untrusted content can influence behavior;

• evaluate quality and safety with representative cases before release;

• log model, prompt, retrieval, policy, and tool versions with the resulting action;

• monitor policy violations, refusal behavior, overrides, quality, latency, and cost;

• provide a safe refusal, escalation, or rollback path.

Guardrails around generated text are useful, but they are not enough when the system can call tools. The business service that performs a refund or changes an order remains responsible for authorization and invariants. The AI component proposes or invokes within a controlled contract; it does not become the source of business authority.

Example: Modernization with Partners and an AI Assistant

A commerce company is moving order processing away from a legacy platform. It must continue exchanging fulfillment updates with warehouse partners and wants to add a support assistant that can explain order status and propose refund actions.

The concern map produces several coordinated choices:

1. Truth: the migration plan names one authoritative order record at each stage. Idempotency keys and reconciliation protect repeated or missing updates.

2. Integration: warehouse updates use versioned business events and durable exception handling because partners change independently.

3. Migration: a stable order API and adapter hide legacy details. Historical data is backfilled and validated before a bounded traffic slice moves. Cutover and rollback conditions are written before authority changes.

4. AI safety: the assistant retrieves only orders the support user may access. It can propose a refund, but the refund service rechecks policy and higher-value refunds require approval. Tool calls and final outcomes are audited.

Now the patterns reinforce each other. Migration reconciliation detects missing partner updates. Integration evidence helps the assistant explain current status. Identity policy limits which order the assistant can retrieve. Governance defines retention for tool-call evidence. Reliability patterns preserve work when a partner is unavailable.

This is why cross-cutting review matters: solving each concern in isolation would miss the boundary between them.

A Practical Selection Sequence

When several concerns appear at once, review them in this order:

1. Name the business outcome and the state that must remain true.

2. Name the authoritative owner before copying or moving data.

3. Classify communication as query, command, event, stream, workflow, or batch.

4. Define timing, ordering, duplicate, schema-change, and replay expectations.

5. Define migration coexistence, cutover, rollback, and retirement.

6. Limit AI retrieval and action to an authorized capability.

7. Add reliability, security, governance, observability, cost, and recovery controls.

8. Decide how reconciliation, evaluation, or another form of evidence will verify the result.

This sequence does not remove trade-offs. It makes them visible before a technology choice hides them.

Common Mistakes

• Treating every copy of data as equally authoritative.

• Choosing an API, queue, event bus, or workflow engine before naming the message's meaning.

• Calling a distributed workflow consistent without defining compensation and reconciliation.

• Using application-level dual writes without durable repair for partial success.

• Moving traffic before validating data, observability, support, and rollback.

• Giving an AI agent broad tools because the human user has broad access.

• Evaluating generated answers while ignoring retrieval authorization and tool outcomes.

• Keeping old integration and migration paths indefinitely after the new path is authoritative.

If Someone Asks You

Which pattern family helps when meaning must cross boundaries safely?

A good answer is:

First name the authoritative truth and the intent crossing the boundary. Use idempotency, outbox, compensation, and reconciliation for distributed state; APIs, commands, events, streams, workflows, or batch according to the communication meaning; staged routing, adapters, validation, cutover, and rollback for migration; and authorized retrieval, scoped tools, approval, evaluation, and monitoring for AI. Then combine the reliability, security, governance, and operating controls that the boundary requires.

What You Should Remember

The hardest patterns protect truth while movement happens.

Questions to Check Your Understanding

1. Why should each migration stage identify one authoritative writer?

2. How does a command differ from an event in intent and ownership?

3. Why must an AI tool enforce business authorization outside the model?

Further Study

• Cloud Design Patterns - Explore patterns for messaging, distributed data, migration, and reliable boundary crossing.

• NIST AI Risk Management Framework - Review a lifecycle-oriented framework for governing, mapping, measuring, and managing AI risk.