Eventually consistent integrations with Dynamics 365

Distributed systems often can't guarantee strong consistency without sacrificing availability or performance. Eventually consistent systems accept temporary inconsistency in exchange for resilience and scale. For Dynamics 365 integrating with other systems, understanding eventual consistency — when it's acceptable and how to operate it — is essential.

The consistency spectrum.

• Strong consistency — all reads see most recent write, immediately.
• Eventual consistency — all replicas converge eventually.
• Causal consistency — if A caused B, B isn't seen before A.
• Read-your-own-writes — user sees their own changes.
• Session consistency — within a session, consistent view.

Different models suit different scenarios.

The CAP theorem. In distributed systems, choose two of three:

• Consistency — all reads see latest write.
• Availability — system responds even during partition.
• Partition tolerance — works despite network failures.

Most modern systems are AP (available, partition-tolerant) with eventual consistency.

Where eventual consistency works.

• Analytics replication — minutes of lag fine.
• Reporting dashboards — slight delay acceptable.
• Search indexes — index can lag behind source.
• CRM master data sync — typical multi-system sync.

Where eventual consistency hurts.

• Financial transactions — bank balance must be accurate.
• Inventory commitments — overselling unacceptable.
• Real-time decisions — fraud screening.
• User-visible immediate feedback.

For these, design for consistency, even at cost of availability or scale.

Convergence time.

• Real-time — seconds.
• Near-real-time — minute to few minutes.
• Batch — hours.

Acceptable convergence varies by use case.

Conflict resolution. When two updates conflict:

• Last-write-wins — based on timestamp.
• Source-priority — one system always wins.
• Custom logic — business rules decide.
• Manual — escalate to human.

Each has trade-offs; clear policy beats ambiguous handling.

Last-write-wins risks.

• Clock skew between systems.
• Conflicting concurrent updates.
• "Lost update" — one update overwrites another.

Use timestamps from authoritative source; or use version vectors / CRDTs for advanced cases.

Idempotency for eventual consistency.

• Same operation may apply twice.
• Receiver must handle.
• Patterns: idempotency key, state-based.

Without idempotency, retries during reconciliation cause issues.

Reconciliation. Periodic process:

• Compare source vs replica.
• Identify discrepancies.
• Resolve.

Healthy eventually-consistent systems have ongoing reconciliation; not assumed correct.

Compensating transactions. When operation fails partway:

• Undo what was done.
• Restore consistent state.
• Saga pattern formalises this.

Saga in distributed transactions; covered in saga pattern guide.

User experience implications.

• "Submit and see result later" — UX makes lag acceptable.
• Optimistic UI — show as if successful; reconcile if not.
• Status indicators — "Processing"; clear feedback.

UX design accommodates eventual consistency.

Read-your-own-writes.

• After user updates, they see updated value.
• Crucial for user trust.
• Achievable with eventual consistency through routing (read from same replica) or pin-to-source.

Often the minimum acceptable consistency.

Patterns to mitigate eventual consistency UX problems.

• Refresh after action — re-fetch post-write.
• Local state — keep client's view consistent.
• Wait and verify — for critical operations.
• Acknowledge before consistent — but communicate clearly.

Dynamics 365 specifics.

• Dataverse to Dataverse cross-environment — eventual.
• Dataverse to F&O via dual-write — near-real-time.
• Dataverse to Synapse/Fabric — eventual (minutes).
• Dataverse to external via API — depends on integration.

Each integration has its consistency characteristic; document and respect.

Testing eventually consistent systems.

• Race condition tests — concurrent updates.
• Lag tests — verify within tolerance.
• Reconciliation tests — discrepancies caught.
• Failure mode tests — what happens if convergence fails.

Specialised testing for distributed correctness.

Monitoring.

• Replication lag — current delay.
• Reconciliation discrepancies.
• Convergence success rate.

Alert when lag exceeds threshold or discrepancies persist.

Common pitfalls.

• Assuming strong consistency. Code breaks under eventual.
• No reconciliation. Drift accumulates.
• No conflict resolution policy. Ad-hoc resolution; data corruption.
• UX assumes immediate visibility. User confused.
• No monitoring of lag. Issues invisible until significant.

Design principles.

• Embrace asynchrony. Don't fight it.
• Idempotent operations.
• Clear conflict policy.
• Periodic reconciliation.
• User-visible status.
• Monitor convergence.

Trade-off conversation. Stakeholders need to understand:

• Strong consistency → more cost, less scale.
• Eventual → cheaper, scalable, but lag.

Make the trade-off explicit; surprise eventual is bad UX.

Strategic positioning. Eventually consistent systems are the default for modern distributed architectures. Understanding when this is appropriate — and when it isn't — is core architectural skill.

For architects:

• Identify consistency requirements per use case.
• Design for the right model.
• Build conflict resolution, idempotency, reconciliation.
• UX accommodates lag.
• Monitor convergence.

The discipline produces robust, scalable integrations that handle real-world distributed-system challenges. The alternative — assuming strong consistency everywhere — produces architectures that don't scale and code that breaks under load. Choose eventual consistency consciously where appropriate; design for it accordingly.