Data Consistency Patterns
Data Consistency Patterns¶
Difficulty: ββββ
Overview¶
Data consistency is one of the most challenging problems in distributed systems. This chapter covers the trade-offs between Strong Consistency and Eventual Consistency, read consistency patterns, limitations of distributed transactions, and the Saga pattern.
Table of Contents¶
- Consistency Models Overview
- Strong vs Eventual Consistency
- Read Consistency Patterns
- Distributed Transactions and 2PC
- Saga Pattern
- Practical Application Guide
- Practice Problems
1. Consistency Models Overview¶
CAP Theorem Review¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β CAP Theorem β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Consistency (C) β
β /\ β
β / \ β
β / \ β
β / CP \ β
β / \ β
β /ββββββββββ\ β
β Availability (A) Partition Tolerance (P) β
β \ AP / β
β \ / β
β \ββββββ/ β
β β
β When Network Partition Occurs: β
β - Choose CP: Maintain consistency, sacrifice availability β
β - Choose AP: Maintain availability, sacrifice consistency β
β (Eventual) β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Consistency Spectrum¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Consistency Spectrum β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Strong Eventual β
β Consistency ββββββββββββββββββββββββββΊ Consistency β
β β
β ββββββββββββ¬βββββββββββ¬βββββββββββ¬βββββββββββ¬βββββββββββ€ β
β β β β β β β β
β Lineariz- Sequential Causal Monotonic Eventual β
β ability Consistency Reads Consistency β
β β
β ββββββββββ Strong Consistency βββββββΊβββββ Weak Consistency βββββΊ β
β ββββββββ Low Availability/Performance βββΊβββ High Availability/Perf βββΊβ
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
2. Strong vs Eventual Consistency¶
Strong Consistency¶
All reads return the result of the most recent write.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Strong Consistency β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Time βββββββββββββββββββββββββββββββββββββββββββββββββββββββΊ β
β β
β Client A: ββββ Write(X=5) ββββββββββββββββββββββββββββββΊ β
β β β
β βΌ β
β Primary: ββββββββ[X=5]βββββββββββββββββββββββββββββββββΊ β
β β β
β β Synchronous replication β
β β (replication completes before write completes) β
β βΌ β
β Replica: ββββββββ[X=5]βββββββββββββββββββββββββββββββββΊ β
β β β
β βΌ β
β Client B: ββββββββ Read() βββββββ returns X=5 βββββββββΊ β
β β
β Characteristics: β
β - All nodes see the same data β
β - Increased write latency β
β - Decreased availability (when replica fails) β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Eventual Consistency¶
Given sufficient time, all reads will return the same value.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Eventual Consistency β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Time βββββββββββββββββββββββββββββββββββββββββββββββββββββββΊ β
β β
β Client A: ββββ Write(X=5) ββββββββββββββββββββββββββββββΊ β
β β β
β βΌ β
β Primary: ββββββββ[X=5]βββββββββββββββββββββββββββββββββΊ β
β β β
β β Asynchronous replication β
β β (write completes immediately, replication later) β
β βΌ β
β Replica: βββ[X=0]ββββββββ[X=5]βββββββββββββββββββββββββΊ β
β β β β
β β replication lag β β
β βΌ βΌ β
β Client B: βββ Read()=0 ββββ Read()=5 ββββββββββββββββββΊ β
β (stale) (current) β
β β
β Characteristics: β
β - Temporary inconsistency allowed β
β - Reduced write latency β
β - High availability β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Trade-off Comparison¶
| Characteristic | Strong Consistency | Eventual Consistency |
|---|---|---|
| Read consistency | Always latest | Temporary lag |
| Write latency | High | Low |
| Availability | Low | High |
| Implementation complexity | High | Low |
| Suitable use cases | Finance, inventory | SNS, like counts |
Selection by Use Case¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Consistency Selection by Use Case β
βββββββββββββββββββββββββββββββββ¬ββββββββββββββββββββββββββββββββββββββββββ€
β Strong Consistency Required β Eventual Consistency Suitable β
βββββββββββββββββββββββββββββββββΌββββββββββββββββββββββββββββββββββββββββββ€
β - Bank account balance β - SNS timeline β
β - Inventory quantity (preventβ - Like/follower counts β
β overselling) β - Search index β
β - Reservation systems β - Log collection β
β - Payment processing β - View counters β
β - User authentication state β - Recommendation systems β
β - Distributed locks β β
βββββββββββββββββββββββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββββ
3. Read Consistency Patterns¶
Read-Your-Writes¶
Guarantees that users can always read the data they wrote.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Read-Your-Writes β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Problem Scenario: β
β ββββββββββββ ββββββββββββ ββββββββββββ β
β β User A β β Primary β β Replica β β
β ββββββ¬ββββββ ββββββ¬ββββββ ββββββ¬ββββββ β
β β β β β
β βββWrite(name=Bob)βββΊβ β β
β ββββ Success βββββββββ β β
β β βββ async replicateββΊβ β
β βββRead(name)βββββββββββββββββββββββββββββΊβ (not replicated yet) β
β βββββββββββββββββββββ name=Alice ββββββββββ β
β β β β
β "I just changed it to Bob, why is it Alice?" β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Solution 1: Read from Primary β
β ββββββββββββ ββββββββββββ β
β β User A β β Primary β β
β ββββββ¬ββββββ ββββββ¬ββββββ β
β β β β
β βββWrite(name=Bob)βββΊβ β
β ββββ Success βββββββββ β
β βββRead(name)ββββββββΊβ β After own write, read from Primary β
β βββββ name=Bob βββββββ β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Solution 2: Timestamp-based β
β β
β - Record timestamp T on write β
β - On read, only read from replicas with data after T β
β - Use only if replica's replication_timestamp >= T β
β β
β Write Response: { success: true, timestamp: T1 } β
β Read Request: { key: "name", min_timestamp: T1 } β
β β Read only from replicas updated after T1 β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
# Read-Your-Writes implementation example
class ReadYourWritesClient:
def __init__(self, primary, replicas):
self.primary = primary
self.replicas = replicas
self.last_write_timestamp = {} # key -> timestamp
def write(self, key, value):
timestamp = self.primary.write(key, value)
self.last_write_timestamp[key] = timestamp
return timestamp
def read(self, key):
if key in self.last_write_timestamp:
# Read recently written keys from Primary
return self.primary.read(key)
else:
# Read unwritten keys from Replica
return self.select_replica().read(key)
Monotonic Reads¶
Guarantees that once a value is read, older values will not be read subsequently.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Monotonic Reads β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Problem Scenario (Monotonic Reads Violation): β
β β
β Time βββββββββββββββββββββββββββββββββββββββββββββββββββββββΊ β
β β
β Replica 1: [v1]βββββββ[v2]βββββββ[v3]βββββββββββββββββββββΊ β
β Replica 2: [v1]βββββββββββββββββββββββ[v2]ββββββββββββββββΊ β
β β
β User: Read@R1=v2 Read@R2=v1 Read@R1=v3 β
β β β β
β βββββββββββ β
β "Feels like time went backwards" β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Solution: Sticky Session β
β β
β ββββββββββββ ββββββββββββ β
β β User A βββββββββββ Replica 1β β
β ββββββββββββ fixed ββββββββββββ β
β β
β ββββββββββββ ββββββββββββ β
β β User B βββββββββββ Replica 2β β
β ββββββββββββ fixed ββββββββββββ β
β β
β - Same user always reads from same replica β
β - Switch to different replica if current one goes down β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Solution: Version-based β
β β
β Read Response: { value: "v2", version: 42 } β
β Next Read Request: { key: "data", min_version: 42 } β
β β Read only from replicas with version >= 42 β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Monotonic Writes¶
Guarantees that writes from the same session are applied in order.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Monotonic Writes β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Problem Scenario: β
β β
β User: Write(X=1) β Write(X=2) β Write(X=3) β
β β
β Due to network latency: β
β Replica receive order: X=2 β X=3 β X=1 β
β Final result: X=1 (not as intended!) β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Solution: Version/Timestamp-based β
β β
β Write(X=1, ts=100) β Write(X=2, ts=101) β Write(X=3, ts=102) β
β β
β Receive order: ts=101 β ts=102 β ts=100 β
β Apply: X=2 applied β X=3 applied β X=1 ignored (ts=100 < current=102) β
β Final result: X=3 (correct!) β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
4. Distributed Transactions and 2PC¶
Two-Phase Commit (2PC)¶
A protocol that guarantees atomicity of distributed transactions.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Two-Phase Commit (2PC) β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Phase 1: Prepare (Voting phase) β
β βββββββββββββββ β
β β Coordinator β β
β ββββββββ¬βββββββ β
β β β
β ββββ PREPARE ββββΊββββββββββββββ β
β β βParticipant1βββββΊ Prepare transaction β
β ββββ VOTE YES βββββββββββββββββ (acquire lock, write log) β
β β β
β ββββ PREPARE ββββΊββββββββββββββ β
β β βParticipant2βββββΊ Prepare transaction β
β ββββ VOTE YES βββββββββββββββββ β
β β β
β Phase 2: Commit (Decision phase) β
β β β
β ββββ COMMIT βββββΊββββββββββββββ β
β β βParticipant1βββββΊ Execute commit β
β βββββ ACK βββββββββββββββββββββ β
β β β
β ββββ COMMIT βββββΊββββββββββββββ β
β β βParticipant2βββββΊ Execute commit β
β βββββ ACK βββββββββββββββββββββ β
β β β
β βΌ β
β Transaction Complete β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
2PC Failure Scenarios¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β 2PC Failure Scenarios β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Scenario 1: Participant votes NO β
β βββββββββββββββ β
β β Coordinator β β
β ββββββββ¬βββββββ β
β ββββ PREPARE ββββΊβParticipant1ββββ VOTE YES β
β ββββ PREPARE ββββΊβParticipant2ββββ VOTE NO (failed) β
β β β
β ββββ ROLLBACK βββΊβParticipant1β β
β ββββ ROLLBACK βββΊβParticipant2β β
β βΌ β
β Transaction Aborted β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Scenario 2: Coordinator Failure (Blocking problem) β
β β
β βββββββββββββββ β
β β Coordinator βββX (failure) β
β ββββββββ¬βββββββ β
β ββββ PREPARE ββββΊβParticipant1ββββ VOTE YES (waiting...) β
β ββββ PREPARE ββββΊβParticipant2ββββ VOTE YES (waiting...) β
β β β
β X Coordinator down! β
β β
β βParticipant1β: "Commit? Rollback? Cannot decide..." β
β βParticipant2β: "Resources remain locked..." β
β β
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β
β This is the biggest problem with 2PC: BLOCKING β
β Participants wait indefinitely until Coordinator recovers β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Limitations of 2PC¶
| Limitation | Description |
|---|---|
| Blocking | Entire system blocks when Coordinator fails |
| Performance | 2 network round trips, all participants wait |
| Availability | Entire transaction rolls back if one participant fails |
| Scalability | Performance degrades rapidly as participants increase |
3PC (Three-Phase Commit)¶
An attempt to mitigate the blocking problem of 2PC:
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β 3PC vs 2PC β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β 2PC: 3PC: β
β 1. Prepare 1. CanCommit (voting) β
β 2. Commit/Rollback 2. PreCommit (prepare confirmation) β
β 3. DoCommit (actual commit) β
β β
β 3PC Advantages: β
β - Participants share state in PreCommit phase β
β - Consensus among participants possible even when Coordinator fails β
β β
β 3PC Limitations: β
β - Still possible inconsistency during network partition β
β - Increased complexity, rarely used in practice β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
5. Saga Pattern¶
A distributed transaction pattern to overcome the limitations of 2PC.
Saga Basic Concept¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Saga Pattern Overview β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β 2PC: One large atomic transaction β
β [βββββββββββ Entire Transaction βββββββββββ] β
β Rollback entire transaction on failure (locks held) β
β β
β Saga: Sequence of local transactions β
β [T1] β [T2] β [T3] β [T4] β
β Execute compensating transactions on failure β
β [T1] β [T2] β [T3-fail] β [C2] β [C1] β
β Compensating transactions β
β β
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β
β β
β Example: Travel Booking Saga β
β β
β Normal flow: β
β [Book Flight] β [Book Hotel] β [Book Car] β [Payment] β
β T1 T2 T3 T4 β
β β
β T3 fails: β
β [Book Flight] β [Book Hotel] β [Car-fail] β [Cancel Hotel] β [Cancel Flight]β
β T1 T2 T3 C2 C1 β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Choreography¶
Each service autonomously operates by publishing and subscribing to events.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Choreography Saga β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β βββββββββββ βββββββββββ βββββββββββ βββββββββββ β
β β Order β β Payment β β Stock β βShipping β β
β β Service β β Service β β Service β β Service β β
β ββββββ¬βββββ ββββββ¬βββββ ββββββ¬βββββ ββββββ¬βββββ β
β β β β β β
β ββββββͺβββββββββββββββͺβββββββββββββββͺβββββββββββββββͺβββ Event Bus β
β β β β β β
β 1.OrderCreated β β β β
β ββββββΌββββββββββββββΊβ β β β
β β 2.PaymentCompleted β β β
β β ββββββΌββββββββββββββΊβ β β
β β β 3.StockReserved β β
β β β ββββββββΌββββββββββββββΊβ β
β β β β 4.ShippingScheduled β
β β β β βββββββββββΌβββββΊ β
β ββββββββββββββββΌβββββββββββββββΌβββββββββββββββΌββββ 5.OrderCompleteβ
β β β β β β
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β
β Compensating events on failure: β
β β
β 1.OrderCreated βββΊ 2.PaymentCompleted βββΊ 3.StockFailed! β
β β β
β PaymentRefunded ββββββββββββ β
β β β
β OrderCancelled βββββ β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Choreography Pros and Cons¶
| Pros | Cons |
|---|---|
| Loose coupling | Difficult to understand overall flow |
| No single point of failure | Risk of circular dependencies |
| Services scale independently | Complex debugging |
| Simple implementation | Difficult testing |
Orchestration¶
A central Orchestrator controls the entire flow.
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Orchestration Saga β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β βββββββββββββββββββ β
β β Orchestrator β β
β β (Saga Manager) β β
β ββββββββββ¬βββββββββ β
β β β
β βββββββββββββββββββββββΌββββββββββββββββββββββ β
β β β β β
β βΌ βΌ βΌ β
β ββββββββββββββ ββββββββββββββ ββββββββββββββ β
β β Order β β Payment β β Stock β β
β β Service β β Service β β Service β β
β ββββββββββββββ ββββββββββββββ ββββββββββββββ β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Normal flow: β
β β
β Orchestrator β
β β β
β βββββ 1. CreateOrder βββββΊβOrderβ β
β βββββ OrderCreated ββββββββ β β
β β β
β βββββ 2. ProcessPayment ββΊβPaymentβ β
β βββββ PaymentDone βββββββββ β β
β β β
β βββββ 3. ReserveStock ββββΊβStockβ β
β βββββ StockReserved βββββββ β β
β β β
β βββββ 4. CompleteOrder βββΊβOrderβ β
β βΌ β
β Saga Complete β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β Compensation on failure: β
β β
β Orchestrator β
β β β
β βββββ 1. CreateOrder βββββΊβOrderβ β β
β βββββ 2. ProcessPayment ββΊβPaymentβ β β
β βββββ 3. ReserveStock ββββΊβStockβ β (failed!) β
β β β
β βββββ 4. RefundPayment βββΊβPaymentβ (compensation) β
β βββββ 5. CancelOrder βββββΊβOrderβ (compensation) β
β βΌ β
β Saga Rolled Back β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Orchestration Pros and Cons¶
| Pros | Cons |
|---|---|
| Centralized flow management | Single point of failure |
| Clear workflow | Increased orchestrator complexity |
| Easy debugging/monitoring | Increased coupling |
| Easy testing | Orchestrator scalability |
Saga Pattern Comparison¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Choreography vs Orchestration Selection Criteria β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Choose Choreography: β
β - When few services (2-4) β
β - Simple workflows β
β - When service independence is important β
β - Want to avoid strong coupling between teams β
β β
β Choose Orchestration: β
β - Complex business logic β
β - When many services (5+) β
β - When clear error handling is needed β
β - When workflow visibility is important β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Saga Implementation Example (Orchestration)¶
class OrderSaga:
"""Order Saga Orchestrator"""
def __init__(self, order_id):
self.order_id = order_id
self.state = "STARTED"
self.compensations = [] # Compensation transaction stack
def execute(self):
try:
# Step 1: Create order
self.create_order()
self.compensations.append(self.cancel_order)
# Step 2: Process payment
self.process_payment()
self.compensations.append(self.refund_payment)
# Step 3: Reserve stock
self.reserve_stock()
self.compensations.append(self.release_stock)
# Step 4: Schedule shipping
self.schedule_shipping()
self.state = "COMPLETED"
except SagaException as e:
self.compensate()
self.state = "COMPENSATED"
raise
def compensate(self):
"""Execute compensating transactions in reverse order"""
while self.compensations:
compensation = self.compensations.pop()
try:
compensation()
except Exception as e:
# Log compensation failure, add to retry queue
log_compensation_failure(self.order_id, compensation, e)
def create_order(self):
# Call Order Service
pass
def cancel_order(self):
# Order Service - cancel order
pass
# ... other methods
6. Practical Application Guide¶
Consistency Pattern Selection Checklist¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Consistency Pattern Selection Guide β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Question 1: What is the impact of data inconsistency on business? β
β βββ Critical (financial loss, legal issues) βββΊ Strong Consistency β
β βββ Acceptable (temporarily stale info) βββΊ Eventual Consistency β
β β
β Question 2: What are the main system requirements? β
β βββ Low latency βββΊ Eventual Consistency β
β βββ Data accuracy βββΊ Strong Consistency β
β β
β Question 3: What should system do on failure? β
β βββ Allow partial functionality outage βββΊ Strong Consistency (CP) β
β βββ Always need to respond βββΊ Eventual Consistency (AP) β
β β
β Question 4: What is the read/write ratio? β
β βββ Read-heavy (90%+) βββΊ Eventual + Read Replica β
β βββ Write-heavy βββΊ Careful! Consider replication lag β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Hybrid Approach¶
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Hybrid Consistency Strategy β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β Apply different consistency levels per data type within same system β
β β
β Example: E-commerce system β
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β
β β Data Type β Consistency Level β Reason β β
β ββββββββββββββββββββββββΌβββββββββββββββββββββΌβββββββββββββββββββ€ β
β β Inventory quantity β Strong β Prevent oversell β β
β β Payment status β Strong β Money accuracy β β
β β Product reviews β Eventual β No immediate needβ β
β β View counts β Eventual β Less important β β
β β Shopping cart β Session β Per-user consist β β
β β Recommended productsβ Eventual β Not real-time β β
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
7. Practice Problems¶
Exercise 1: Analyze Consistency Requirements¶
Choose an appropriate consistency model for the following scenarios and explain why:
- Bank account balance
- Twitter follower count
- Online game ranking
- Airline seat reservation
- News article view count
Exercise 2: Saga Design¶
Design an order process for an online shopping mall using the Saga pattern: - Include steps: order creation, inventory check, payment, shipping reservation - Define compensating transactions for each step - Design both Choreography and Orchestration versions
Exercise 3: Read Consistency Implementation¶
Design a client library that guarantees Read-Your-Writes: - Guarantee latest data on read after write - Use timestamp-based approach - Include caching strategy
Next Steps¶
In 11_Message_Queue_Basics.md, let's learn about message queues, the foundation of asynchronous communication!
References¶
- "Designing Data-Intensive Applications" - Martin Kleppmann
- "Microservices Patterns" - Chris Richardson
- Google Cloud Spanner: TrueTime and External Consistency
- AWS: Building Distributed Locks with DynamoDB
- "Sagas" - Hector Garcia-Molina, Kenneth Salem (1987)