Consistency and transactions

← Back to System Design

Consistency And Transactions Deep Dive

Overview

Distributed systems trade strict consistency for availability and latency under failure.

Core Concepts

• Strong consistency for critical invariants.
• Eventual consistency for scalable derived views.
• Idempotency and ordering are essential for retries.

Internal Architecture

• Transaction boundary lives inside one service/database when possible.
• Cross-service workflows use sagas and compensating actions.

Data and Request Flow

• Command accepted -> durable write -> outbox event.
• Consumers apply events idempotently.
• Reconciliation jobs correct drift over time.

Scalability and Reliability

• Exactly-once is expensive; aim for effectively-once via idempotency.
• Include dedupe keys and replay-safe handlers.

Code Examples

Order Created -> Payment Reserved -> Inventory Reserved -> Confirmed
                      on failure -> Compensation steps

Common Interview Questions

• Q: When do you use ACID transactions? A: Structure the answer as constraints then tradeoffs: SLOs, capacity assumptions, bottlenecks, failure modes, and mitigation plans with clear triggers.
• Q: How do you explain saga failure handling? A: Structure the answer as constraints then tradeoffs: SLOs, capacity assumptions, bottlenecks, failure modes, and mitigation plans with clear triggers.
• Q: How do you guarantee no duplicate side effects? A: Structure the answer as constraints then tradeoffs: SLOs, capacity assumptions, bottlenecks, failure modes, and mitigation plans with clear triggers.

Production Considerations

• Keep audit trails for state transitions.
• Provide operator tooling for stuck workflows.

Tradeoffs

• Transactional simplicity vs cross-service scalability.
• Immediate consistency vs higher throughput.

Senior-Level Insights

• Mature designs include reconciliation and operational playbooks.