Azure Architecture Guide

CH21-09: Data Consistency and Distributed Transactions

Goal

Help readers connect data consistency and distributed transaction concerns to Azure solution options, useful patterns, trade-offs, and decision prompts.

The Short Version

Distributed data design decides where strong consistency is required and where eventual consistency can be managed safely.

When services and data stores are separated, the architecture must be honest about which business rules need immediate correctness and which states can be synchronized through messages, workflows, projections, compensation, or reconciliation. The answer is rarely make every service share one database and rarely everything can be eventually consistent.

Concern

The workload must keep business data correct while services, databases, messages, and workflows are separated across boundaries.

Typical Symptoms

  • Multiple services write the same data store.

  • Teams expect one transaction to cover several services.

  • Retries create duplicate payments, orders, or inventory reservations.

  • Reports disagree because each service owns a different view of the truth.

  • Compensation and reconciliation are handled manually after incidents.

Azure Solution Options

  • Keep strongly consistent operations inside one service and database boundary where possible.

  • Use Service Bus for durable messages and idempotent processing.

  • Use event-driven projections or read models for cross-service queries.

  • Use Cosmos DB, Azure SQL, or other data services based on consistency, transaction, and access needs.

  • Use workflow orchestration where business processes need visible state and compensation.

Useful Patterns

  • CQRS.

  • Event Sourcing.

  • Saga.

  • Compensating Transaction.

  • Queue-Based Load Leveling.

  • Idempotent Receiver concepts.

Trade-Offs

  • Strong consistency simplifies correctness but can limit service independence and scale.

  • Eventual consistency improves independence but requires user experience, retries, and reconciliation design.

  • Sagas make long-running workflows explicit but add state and compensation complexity.

  • Read models improve query performance but introduce projection freshness concerns.

Decision Prompt

Which business invariant must be immediately consistent, and which state can become consistent through a controlled process?

Common Mistakes

  • Splitting services while keeping one shared write database.

  • Assuming distributed transactions are the normal answer for microservices.

  • Retrying non-idempotent operations without safeguards.

  • Hiding eventual consistency from users and support teams.

If Someone Asks You

How do you handle data consistency across Azure services?

I keep critical invariants inside clear service and database boundaries where possible. For distributed processes, I use durable messaging, idempotent handlers, workflow state, sagas, compensating actions, read models, and reconciliation so the system can move toward consistency safely. I also make eventual consistency visible to users and support teams instead of hiding it behind misleading status.

What You Should Remember

Keep critical invariants inside clear boundaries, and manage distributed state with messages, idempotency, compensation, and visibility.

Questions to Check Your Understanding

  1. Why are shared write databases risky in microservices?

  2. What does idempotency protect against?

  3. When might a saga or compensating transaction be needed?