Part 044 — Transactional Boundaries, Isolation, Optimistic Concurrency, Sagas, and Consistency Models

Positioning

Quote-to-Order terdiri dari banyak authoritative contexts:

• Catalog;
• Pricing;
• Quote;
• Approval;
• Agreement;
• Product Order;
• Fulfillment;
• Product Inventory;
• Billing.

Tidak ada satu transaction database yang secara realistis dapat mencakup semuanya tanpa mengorbankan:

• availability;
• autonomy;
• scalability;
• dan evolvability.

Namun “eventual consistency” juga bukan alasan untuk menerima data yang ambigu atau invariant yang rusak.

Core thesis: consistency harus dirancang per invariant. Gunakan local ACID untuk aggregate invariants, optimistic concurrency untuk stale writes, reservations untuk scarce/exclusive intent, sagas/process managers untuk long-running cross-context work, dan reconciliation untuk convergence. Distributed transaction bukan default; compensation juga bukan rollback sempurna.

1. Consistency

Consistency berarti sistem mematuhi invariants dan menyajikan facts sesuai authority/contract.

2. Strong Consistency

A read after successful write observes latest committed value under defined scope.

3. Eventual Consistency

Replicas/contexts converge over time if no new updates occur.

4. Causal Consistency

Effects are observed after their causes.

5. Read-Your-Writes

A client sees its own committed writes.

6. Monotonic Reads

A client does not see older version after newer version.

7. Monotonic Writes

Writes from one client are applied in order.

8. Session Consistency

Consistency guarantees scoped to one client session.

9. Bounded Staleness

Data may lag within explicit time/version bound.

10. Consistency Is Scoped

Ask:

• consistency of what fact?
• within what boundary?
• for which consumer?
• over what time?
• and under what failure?

11. Invariant-Driven Consistency

Examples:

• one Offer can be accepted once;
• one Acceptance/group creates one Product Order;
• one Product modification applies to expected Product version;
• one accepted charge creates one Billing charge.

12. Local Invariant

Can be protected in one aggregate/database transaction.

13. Cross-Context Invariant

Requires coordination, reservation, idempotency, saga, or reconciliation.

14. Immediate Invariant

Must hold at commit.

15. Convergent Invariant

May be temporarily violated but must converge within controlled process.

16. Safety Invariant

Must never be violated.

Examples:

• cross-tenant access;
• duplicate financial charge;
• unauthorized acceptance.

17. Liveness Property

Something good eventually happens.

Example:

• accepted Offer eventually produces Order or explicit failure.

18. Safety versus Liveness

Strong safety may reduce liveness under partition.

Design trade-offs explicitly.

19. CAP Perspective

Under network partition, distributed system must choose between some forms of consistency and availability for a given operation.

20. CAP Misuse

CAP does not mean every system simply chooses “two of three” globally.

21. PACELC Perspective

Even without partition, systems trade latency versus consistency.

22. Authority

Consistency starts by defining authoritative owner for each fact.

23. Local Snapshot

A context may store immutable external evidence.

24. Projection

A read model can lag authority.

25. Cache

A cache can be stale and should not become hidden authority.

26. Transaction

A transaction groups operations with atomicity, consistency, isolation, and durability within a supported boundary.

27. Atomicity

All local transaction changes commit or none commit.

28. Consistency in ACID

Database constraints and application logic preserve invariants.

29. Isolation

Concurrent transactions behave according to isolation level.

30. Durability

Committed state survives failures according to storage guarantees.

31. Transaction Boundary

Usually one aggregate or a small set of tightly coupled aggregates in one context/database.

32. Long Transaction Smell

Keeping DB transaction open during:

• external API call;
• human approval;
• file generation;
• or customer response

is unsafe.

33. Long-Running Business Transaction

Use saga/process manager, not one database transaction.

34. Isolation Levels

Common conceptual levels:

• Read Uncommitted;
• Read Committed;
• Repeatable Read;
• Serializable;
• Snapshot Isolation.

Exact behavior depends on database.

35. Dirty Read

Read uncommitted data.

36. Non-Repeatable Read

Same row read twice yields different committed value.

37. Phantom Read

Repeated predicate query returns changed row set.

38. Lost Update

Concurrent writes overwrite each other.

39. Write Skew

Two transactions read same condition and write different rows, violating cross-row invariant.

40. Read Skew

Related values observed from different moments.

41. Serialization Anomaly

Outcome not equivalent to any serial execution.

42. Snapshot Isolation

Prevents many anomalies but can allow write skew.

43. Serializable Isolation

Strongest common isolation, with concurrency cost/retries.

44. Isolation Choice

Choose based on invariant, contention, and workload.

45. Database Constraint

Use unique/check/foreign-key/exclusion constraints for invariants where possible.

46. Unique Constraint

Examples:

one Acceptance per Offer
one Order per Acceptance/group
one Billing Charge per accepted charge generation

47. Check Constraint

Protect local value/state rules.

48. Foreign Key

Protect reference existence within same ownership boundary.

49. Exclusion Constraint

Can prevent overlapping reservations/effective periods where database supports it.

50. Application Guard

Needed for richer domain invariant.

51. Constraint plus Application Logic

Use both:

• domain explanation;
• database last line of defense.

52. Optimistic Concurrency

Assumes conflicts are uncommon and detects stale writes.

53. Version Column

Example:

version = 17

54. Compare-and-Set

Update only if expected version matches.

55. ETag/If-Match

HTTP representation of optimistic concurrency.

56. Optimistic Lock Failure

Should return conflict/precondition failure with current version or reload guidance.

57. Blind Retry Risk

A stale command may no longer be valid.

58. Safe Automatic Retry

Possible when operation can be recomputed without changing intent.

59. Semantic Retry

Reload current state, re-evaluate command, and apply if still valid.

60. Merge

Combines concurrent changes.

61. Field-Level Merge

Safe only for independent fields.

62. Semantic Conflict

Examples:

• one user removes item while another edits it;
• approval is granted while price changes;
• one Order modifies Product while another terminates it.

63. Conflict Resolution Policy

Possible:

• reject;
• last acceptable command wins;
• merge independent changes;
• branch/revision;
• or manual resolution.

64. Last-Write-Wins Risk

Timestamps do not understand business semantics.

65. Pessimistic Concurrency

Locks state before change.

66. Row Lock

Useful for short local critical section.

67. Lock Timeout

Prevent indefinite waits.

68. Deadlock

Transactions wait cyclically for locks.

69. Deadlock Handling

Database aborts one transaction; application retries if safe.

70. Lock Ordering

Consistent acquisition order reduces deadlocks.

71. Long-Lived Lock Anti-Pattern

Do not hold DB lock across human or distributed process.

72. Domain Reservation

Represents temporary claim on domain resource.

73. Reservation Use Cases

• Product change;
• capacity;
• promotion;
• inventory stock;
• quote number;
• and appointment slot.

74. Reservation Identity

Store:

• owner;
• scope;
• quantity;
• validity;
• and source process.

75. Reservation State

Possible:

• REQUESTED;
• HELD;
• CONFIRMED;
• RELEASED;
• EXPIRED;
• FAILED.

76. Reservation Expiry

Prevents abandoned claims.

77. Reservation Renewal

Must verify ownership/current version.

78. Reservation Confirmation

Converts temporary hold to committed allocation.

79. Reservation Release

Idempotent and owner-scoped.

80. Soft Reservation

Indicative and not guaranteed.

81. Hard Reservation

Stronger exclusive commitment.

82. Overbooking

Explicit policy, not accidental race.

83. Reservation Leak

Expired/cancelled process leaves held resource.

84. Reservation Reconciliation

Detect and release stale holds safely.

85. Lease

Time-bound ownership of work/resource.

86. Lease Expiry

Another worker may take over.

87. Stale Lease Holder

Old worker may continue after pause/network delay.

88. Fencing Token

Monotonic token prevents stale holder from performing protected effect.

89. Distributed Lock

Provides mutual exclusion under limited conditions.

90. Distributed Lock Is Not Transaction

It does not make multiple side effects atomic.

91. Lock Safety

Requires:

• ownership token;
• expiry;
• clock/partition assumptions;
• and fencing where needed.

92. Advisory Lock

Application-coordinated lock in database.

Useful locally, not a universal distributed solution.

93. Single Writer

Route all updates for one aggregate/key to one logical writer.

94. Actor Model

Actor serializes messages for one entity.

95. Partitioned Command Processing

Key commands by aggregate ID.

96. Single Writer Limitation

Failover and external effects still require idempotency.

97. Multi-Leader Conflict

Harder for transactional domain state.

98. CRDT

Conflict-free replicated data type.

99. CRDT Suitability

Good for mathematically mergeable data.

Less suitable for invariants like:

• one acceptance;
• one charge;
• exclusive reservation.

100. Commutative Operation

Order-independent operation can simplify concurrency.

101. Idempotent Operation

Repeat-independent operation.

102. Monotonic Operation

State moves one direction.

103. Monotonic State Machine

Terminal states cannot regress.

104. Concurrency in Quote Editing

Multiple collaborators may edit different Quote items.

105. Quote Revision Strategy

Options:

• one aggregate version;
• item versions;
• revisions/branches;
• command log;
• collaborative CRDT for text only.

106. Item-Level Concurrency

Reduces conflicts for large Quotes.

107. Finalization Barrier

Ensures all item partitions align with one revision manifest.

108. Acceptance Race

Accept competes with:

• expiry;
• withdrawal;
• supersession;
• and reprice.

Use atomic state guard.

109. Approval Race

Approval decision competes with Quote change.

Bind decision to exact revision/snapshot.

110. Price Race

Price validity expires while acceptance is submitted.

Atomic acceptance guard checks authoritative time and snapshot.

111. Product Inventory Race

Two Orders modify same Product.

Use:

• expected Product version;
• pending-action reservation;
• or conflict matrix.

112. Billing Race

Activation and stop arrive concurrently/out of order.

Use charge generation/version and state guards.

113. Cancellation Race

Cancellation competes with completion.

Use expected versions and irreversible-effect policy.

114. Retry Race

Scheduled retry competes with late success callback.

Use attempt/generation guard.

115. Timeout Race

Caller times out while server commits.

Idempotency and status query recover outcome.

116. Distributed Transaction

Coordinates atomic commit across multiple participants.

117. Two-Phase Commit

Coordinator asks participants to prepare, then commit/rollback.

118. 2PC Benefits

Stronger atomicity across participating transactional resources.

119. 2PC Costs

• blocking;
• coordinator dependency;
• operational complexity;
• latency;
• limited external-system support;
• and tight coupling.

120. 2PC Suitability

May be acceptable in constrained homogeneous environments.

Rarely suitable across SaaS, supplier, Billing, human workflow, and long-running fulfillment.

121. XA

A standard for distributed transaction coordination among compatible resources.

122. XA Limitations

External APIs and brokers may not participate meaningfully.

123. Distributed Transaction Myth

Calling multiple services in one request does not make operation atomic.

124. Saga

Sequence of local transactions coordinated over time.

125. Saga Step

Each step has:

• command;
• local transaction;
• result event;
• timeout;
• and optional compensation.

126. Saga Orchestration

Central process manager directs steps.

127. Saga Choreography

Services react to events.

128. Saga State

Must be durable and versioned.

129. Saga Correlation

Use process/business identities.

130. Saga Compensation

Forward action to offset prior effect.

131. Compensation Is Not Automatic

Each step must define whether and how compensation works.

132. Non-Compensatable Step

Examples:

• customer email sent;
• physical work completed;
• invoice posted;
• external manufacturing started.

133. Pivot Transaction

Saga step after which compensation is no longer normal rollback path.

134. Compensatable Transaction

Can be undone/offset before pivot.

135. Retryable Transaction

Can be retried until success after pivot.

136. Saga Completion

All required steps reach accepted terminal outcome.

137. Saga Partial Completion

Some effects remain.

Must be explicit.

138. Saga Timeout

Triggers reconciliation, retry, compensation, or manual review.

139. Saga Isolation Problem

Other transactions can observe intermediate saga state.

140. Semantic Lock

Mark resource as pending/in-process.

141. Commutative Updates

Design saga steps to tolerate interleaving.

142. Pessimistic View

Other flows block or respect pending state.

143. Reread Before Commit

Validate assumptions before irreversible step.

144. Version File/Countermeasure

Track saga generation/version on affected entities.

145. Process Manager

Stores saga state and issues commands.

146. Workflow Engine

Can implement durable process manager.

147. Choreography Limitation

Complex compensation and visibility become difficult.

148. Orchestration Limitation

Coordinator can become overly coupled or central bottleneck.

149. Hybrid Saga

Central high-level process, domain-local choreography/internal workflows.

150. Quote-to-Order Saga

Illustrative steps:

Acceptance committed
-> Agreement create/resolve
-> Product Orders create
-> Fulfillment Plans create
-> Orders submitted
-> Billing handoff later

151. Acceptance Compensation

Usually do not “unaccept” because downstream technical step failed.

Commercial truth remains; process enters fallout.

152. Agreement Step Failure

Retry, manual review, or commercial process.

153. Product Order Create Failure

Retry idempotently or reconcile ambiguous outcome.

154. Fulfillment Failure

Recover, compensate, replan, or close partial.

155. Billing Failure

Does not erase Product activation; opens Billing fallout.

156. TCC Pattern

Try–Confirm/Cancel.

157. Try Phase

Reserve tentative resources.

158. Confirm Phase

Commit reservations.

159. Cancel Phase

Release tentative reservations.

160. TCC Use Cases

• capacity;
• inventory stock;
• appointment;
• payment authorization;
• and limited promotion entitlement.

161. TCC Limitation

Participants must implement tentative semantics.

162. Reservation Pattern versus TCC

Reservation can be simpler domain-specific form of TCC.

163. Outbox Pattern

Atomic local state + event intent.

164. Inbox Pattern

Atomic dedupe + local effect.

165. Outbox/Inbox Are Not Distributed Transactions

They support reliable eventual coordination.

166. Transactional Messaging

Aligns database and messaging within local boundaries.

167. Change Data Capture

Can publish committed changes.

168. CDC Semantic Risk

Raw row changes may not represent domain facts.

169. Dual Write

Write local DB and remote system independently.

170. Dual-Write Failure Matrix

171. Compensating Dual Write

Attempt reverse remote/local effect.

May be partial.

172. Prefer Local Commit First

Often commit authoritative local intent and reliably publish command/event.

173. Remote First Risk

Remote effect succeeds, local record fails.

Requires remote idempotency/reference and reconciliation.

174. Local First Risk

Local state exists while remote not yet applied.

Model pending state and retry.

175. Operation Resource

Tracks asynchronous distributed operation.

176. Operation Identity

Supports retries and status query.

177. Pending State

A valid business state, not necessarily failure.

178. Unknown State

Actual outcome uncertain.

179. Reconciliation

Essential for unknown and eventual consistency.

180. Read Model Consistency

Projection may lag commands.

181. Command Query Responsibility Segregation

Separate write model and read projections.

182. CQRS

Can optimize complex domains/read models.

Not required for every service.

183. CQRS Cost

• more models;
• eventual consistency;
• projection operations;
• and debugging complexity.

184. Read-Your-Write with CQRS

Return authoritative command result or consistency token.

185. Projection Version

Expose last applied aggregate/event version.

186. Consistency Token

Client can request/read until minimum version.

187. Synchronous Read-Back

Query write store after command if required.

188. Cache Consistency

Invalidate/update cache after authoritative commit.

189. Cache-Aside

Application loads on miss and invalidates on write.

190. Write-Through Cache

Cache and store updated together through one path.

191. Write-Behind Cache Risk

Delayed durable write can violate critical invariants.

192. Cache Stampede

Many clients reload same key.

193. Stale Cache Guard

Use version/TTL and avoid cache for command decisions.

194. Distributed Cache Lock Risk

Do not treat cache lock as strong business transaction without guarantees.

195. Replication

Database replicas may lag.

196. Read Replica

Good for queries, dangerous for immediate post-write validation.

197. Replica Lag

Can cause false missing state.

198. Read Routing

Critical consistency reads go to primary/authority.

199. Multi-Region

Introduces latency, partition, and conflict challenges.

200. Active-Passive

Single write region; failover.

201. Active-Active

Multiple write regions; conflict handling required.

202. Region Affinity

Route aggregate/tenant writes consistently.

203. Cross-Region Ordering

Difficult; use scoped sequence/authority.

204. Failover

Must preserve:

• idempotency records;
• outbox;
• sequence;
• and fencing.

205. Split Brain

Two regions believe they are writer.

206. Fencing after Failover

Reject stale writer.

207. RPO

Potential data-loss window.

208. RTO

Recovery-time target.

209. Business Consistency under DR

Define which in-flight operations may be:

• replayed;
• reconciled;
• or manually reviewed.

210. Time

Distributed consistency often depends on time.

211. Clock Skew

Machines disagree on current time.

212. Wall Clock

Human/business timestamps.

213. Monotonic Clock

Useful for durations/timeouts locally.

214. Authoritative Business Time

For expiry/acceptance, define one trusted evaluation point.

215. Effective Time

When business change applies.

216. Recorded Time

When stored.

217. Processing Time

When handler executes.

218. Event Time

When source fact occurred.

219. Watermark

Stream-processing estimate that events before time likely arrived.

220. Late Event

Requires explicit update/reconciliation behavior.

221. Temporal Consistency

Effective-dated records must avoid overlaps/gaps where prohibited.

222. Effective Period Constraint

Can use application validation/database exclusion constraint.

223. Future-Dated Change

Current and scheduled states coexist.

224. Cancellation of Scheduled Change

Requires identity/version.

225. Transaction Retry

Database may abort due to deadlock/serialization conflict.

226. Retry Scope

Retry entire local transaction with fresh state.

227. Side Effect inside Transaction

Do not call non-idempotent external API inside retried DB transaction.

228. After-Commit Hook

Publish via outbox, not direct best-effort call.

229. Transactional Event Listener Risk

Listener timing/rollback semantics must be explicit.

230. Domain Event Collection

Aggregate can record domain events during command.

Application persists aggregate and outbox.

231. Unit of Work

Tracks aggregates and transaction.

232. Transaction Boundary in Java

Framework annotation is not domain design.

233. Nested Transaction

Semantics differ by framework/database.

Use carefully.

234. Requires New Transaction

Can commit audit/outbox unexpectedly if outer fails.

Understand semantics.

235. Transaction Propagation Smell

Business consistency hidden in annotations.

236. Lazy Loading Risk

Aggregate accesses database outside expected transaction.

237. ORM Lost Update

Without version column, stale entity may overwrite changes.

238. Bulk Update Risk

Bypasses entity version/domain guards.

239. Database Trigger

Can protect local invariant, but hidden domain behavior and event publication complicate ownership.

240. Stored Procedure

Can enforce strong local consistency for specialized operations.

Must remain governed/documented.

241. Batch Job Concurrency

Batch and online commands may update same state.

242. Batch Claim

Use version/claim/lease.

243. Skip-Locked Pattern

Useful for worker queues, with starvation considerations.

244. Work Stealing

Workers take available partitions/tasks.

245. Exactly-Once Batch Effect

Use business key/idempotency per item.

246. Bulk Transaction Size

Large transactions increase lock, log, and recovery cost.

247. Chunking

Process bounded chunks with per-item outcomes.

248. Partial Batch Failure

Track succeeded/failed/unknown items.

249. Concurrency Testing

Test:

• two accept commands;
• accept versus withdraw;
• modify versus terminate Product;
• cancel versus complete Order;
• and retry versus late callback.

250. Isolation Testing

Reproduce:

• lost update;
• write skew;
• phantom;
• and serialization retries.

251. Fault Injection

Inject failures:

• before commit;
• after commit;
• before publish;
• after remote success;
• and during compensation.

252. Jepsen-Style Thinking

Test system invariants under partition, delay, duplication, and process failure.

253. Model-Based Testing

Generate command sequences and verify invariants.

254. Property-Based Testing

Properties:

• one Offer has at most one effective Acceptance;
• duplicate command yields one effect;
• stale Product version cannot update;
• and saga terminal state has complete outcome classification.

255. Reconciliation Testing

Create intentional divergence and verify convergence.

256. Disaster Recovery Test

Verify in-flight operations after failover.

257. Consistency Observability

Track:

• conflict rate;
• retry rate;
• reservation leaks;
• saga age;
• and reconciliation backlog.

258. Version Conflict Metric

High rate may indicate poor aggregate boundary or UX.

259. Serialization Failure Metric

Can reveal contention hotspot.

260. Deadlock Metric

Track tables/operations involved.

261. Saga Stuck Metric

Long-running process without progress.

262. Unknown Outcome Metric

High-risk distributed ambiguity.

263. Reservation Metrics

• active;
• expired;
• leaked;
• and contention.

264. Projection Lag

Read-model freshness.

265. Reconciliation Mismatch

Count by invariant and authority.

266. Consistency SLI

Examples:

• zero duplicate Acceptance/Product Order/Billing Charge;
• all stale writes rejected;
• all unknown outcomes reconciled within target;
• and all expired reservations released.

Internal targets must be verified.

267. Consistency Incident

Examples:

• duplicate Acceptance;
• two Orders modify same Product;
• Billing charge created twice;
• old event reactivates terminated Product;
• and saga marked completed with failed required step.

268. Incident Containment

Possible:

• freeze aggregate;
• stop commands;
• pause consumer;
• preserve evidence;
• identify authoritative state;
• and reconcile affected scope.

269. Consistency Smells

• “eventual consistency” used without convergence process;
• no authority matrix;
• and generic latest-wins merge.

270. Concurrency Smells

• no version column;
• retry all conflicts blindly;
• and long-lived DB locks.

271. Transaction Smells

• external API inside DB transaction;
• shared transaction across service boundaries assumed;
• and multi-service rollback expectation.

272. Saga Smells

• no durable saga state;
• compensation undefined;
• and acceptance reverted after fulfillment failure.

273. Reservation Smells

• no expiry;
• release by resource only without owner token;
• and check treated as reservation.

274. Cache/Replica Smells

• stale cache used for command guard;
• read replica used for immediate uniqueness decision;
• and negative cache hides new Product.

275. Anti-Patterns

Distributed ACID by Hope

Multiple HTTP calls are not atomic.

Eventual Consistency without Reconciliation

Divergence becomes permanent.

Last Write Wins

Business conflict is hidden.

Retry Stale Command

Intent may no longer be valid.

Lock across Human Workflow

Availability collapses.

Compensation as Rollback

Irreversible effects disappear from model.

2PC across External Providers

Participants cannot support real atomicity.

Read Replica for Critical Guard

Stale data permits invalid command.

276. Consistency Decision Template

## Invariant

## Authority / Scope

## Immediate or Eventual

## Transaction Boundary

## Concurrency Strategy

## Reservation / Lock

## Failure Behavior

## Reconciliation

## Observability

## Recovery

277. Aggregate Transaction Template

Aggregate:
Command:
Expected version:
Reads:
Writes:
Database constraints:
Isolation:
Domain events:
Outbox:
Retry policy:

278. Saga Template

## Saga Identity and Version

## Business Goal

## Correlation / Idempotency

## Steps

## Commands / Events

## Timeouts

## Retry Policies

## Compensations

## Pivot / Irreversible Steps

## Partial Outcomes

## Manual Recovery

## Reconciliation

## Completion Invariants

279. Reservation Template

Reservation:
Resource/scope:
Owner process:
Quantity:
Soft/hard:
Version/token:
Created:
Expires:
Confirm:
Release:
Reconciliation:

280. Concurrency Conflict Template

Resource:
Expected version/state:
Actual version/state:
Command intent:
Conflicting operation:
Safe merge:
Resolution:
Customer/business impact:

281. Reconciliation Template

Invariant:
Authority sources:
Expected:
Observed:
Consistency window:
Classification:
Repair:
Evidence:
Owner:

282. Isolation Review Template

Operation:
Read/write set:
Invariant:
Potential anomaly:
Isolation level:
Constraint/lock/version:
Retry:
Performance impact:

283. Consistency Invariants

Representative invariants:

• local aggregate transitions are atomic;
• stale commands cannot overwrite newer state;
• unique business outcomes are protected by constraints/idempotency;
• reservations are owner-scoped and expire safely;
• saga steps are durable and idempotent;
• compensation preserves residual effects;
• projections never become hidden authority;
• and all eventual invariants have reconciliation/operational ownership.

284. Worked Example: Concurrent Offer Acceptance

Two requests arrive.

Transaction:

• checks PRESENTED state;
• inserts unique Acceptance;
• changes state;
• writes outbox.

One succeeds; one receives duplicate/conflict with original Acceptance.

285. Worked Example: Accept versus Withdraw

Both commands use expected Offer version.

Only one transition commits.

The loser observes terminal state.

286. Worked Example: Quote Collaboration

Two users edit independent item partitions.

Both succeed.

Finalization manifest pins exact partition versions.

287. Worked Example: Approval Stale Revision

Approval is bound to Quote revision 6.

Quote becomes revision 7.

Presentation guard rejects old approval evidence.

288. Worked Example: Product Modify Race

Order A and Order B both target Product version 10.

Order A updates to 11.

Order B fails expected-version guard and enters revalidation.

289. Worked Example: Capacity Reservation

Two Orders request final port.

Atomic reservation allows one hard hold.

Other Order waits or replans.

290. Worked Example: Product Order Saga

Acceptance triggers Agreement resolution and two Product Orders.

One Order create response is lost.

Saga reconciles by Acceptance/group key before retry.

291. Worked Example: Billing Activation Saga

Product activates.

Billing handoff creates charge.

Response times out.

Charge lookup finds existing result; saga marks step complete.

292. Worked Example: Compensation

Supplier order placed, later customer cancels.

Cancellation requests supplier cancel.

Supplier cannot reverse manufacturing.

Saga records residual cost and commercial remedy rather than pretending rollback.

293. Worked Example: Read Replica Lag

Immediately after Product activation, replica still shows pending.

Billing activation guard reads authority/uses event source version, not stale replica.

294. Worked Example: Write Skew

Two approval delegates each see “no active delegation” and create overlapping records.

Use serializable transaction or exclusion constraint.

295. Worked Example: Deadlock Retry

Two transactions update items in opposite order.

Database aborts one.

Application retries complete local command with fresh state.

296. Worked Example: Cache Staleness

Promotion availability cache says one redemption left.

Atomic authoritative reservation prevents two customers consuming it.

297. Worked Example: Region Failover

Old region worker resumes after failover.

Fencing token rejects stale writes.

298. Worked Example: Projection Lag

Order command succeeds.

Search projection lags.

API returns authoritative Order reference/version and operation status instead of false “not found”.

299. Worked Example: Scheduled Change

Future Product termination is created.

A later renewal cancels/supersedes scheduled change using explicit identity/version.

300. Worked Example: Systemic Duplicate Charge

A consumer loses inbox deduplication.

Duplicate Billing charges appear.

Containment pauses consumer, reconciles by accepted charge ID, reverses duplicates, and restores idempotency.

301. Senior Engineer Operating Model

Start from invariants

Do not choose consistency globally.

Keep local ACID local

Aggregate/context transaction boundaries.

Use optimistic concurrency by default

And semantic conflict handling.

Use reservations for scarce/exclusive intent

Not long-lived locks.

Treat distributed workflows as sagas

With durable state, retries, and residual outcomes.

Do not compensate commercial truth casually

Acceptance and Agreement facts remain.

Design for ambiguity

Operation identity and reconciliation.

Keep projections and caches non-authoritative

Critical guards use authority/version.

Test under concurrency and failure

Not only happy-path unit tests.

Operate consistency

Conflicts, stuck sagas, reservation leaks, and reconciliation backlog.

302. Internal Verification Checklist

Invariants and authority

• Invariant mana yang harus strong consistency?
• Which facts may be eventually consistent?
• Who is authority for each fact?
• Are safety and liveness expectations explicit?

Aggregate/local transactions

• What is each transaction boundary?
• Are database constraints used?
• Which isolation level applies to critical operations?
• Are external calls excluded from local transactions?

Concurrency

• Bagaimana optimistic locking diterapkan?
• Are ETag/expected versions exposed?
• Which conflicts can merge?
• Which commands require semantic revalidation?

Reservations/leases

• What scarce/exclusive resources are reserved?
• Are reservations owner-scoped, versioned, and expiring?
• Are fencing tokens required?
• How are leaks reconciled?

Distributed workflows

• Apakah saga atau process manager digunakan?
• Which steps are compensatable, retryable, or irreversible?
• Where is pivot/point of no return?
• Are partial outcomes first-class?

Messaging

• Are outbox/inbox patterns used?
• Are consumers idempotent?
• Can old/out-of-order events regress state?
• Are operation outcomes queryable?

Reads/caches/replicas

• Which reads require authority or read-your-write?
• Are caches/projections used in command guards?
• How is replica lag handled?
• Are consistency tokens/versions exposed?

Operations and DR

• Are conflicts, deadlocks, stuck sagas, unknown outcomes, and reservation leaks monitored?
• How are region failover and stale writers fenced?
• What reconciliation jobs exist?
• What incidents reveal incorrect transaction assumptions?

303. Practical Exercises

Exercise 1 — Invariant classification

Classify 50 invariants as local immediate, distributed safety, or eventual convergence.

Exercise 2 — Isolation anomaly

Reproduce lost update, write skew, phantom, and deadlock scenarios.

Exercise 3 — Saga design

Design Quote-to-Order saga with retries, compensation, and irreversible steps.

Exercise 4 — Reservation

Model capacity, Product-change, promotion, and appointment reservations.

Exercise 5 — Read consistency

Design read-your-write across command store, projection, cache, and replica.

Exercise 6 — Failure test

Inject commit/publish/timeout/failover failures and verify reconciliation.

304. Part Completion Checklist

You are done if you can:

• define consistency per invariant;
• choose local transaction boundaries;
• identify isolation anomalies;
• enforce optimistic concurrency and database constraints;
• design semantic conflict handling;
• use reservations, leases, and fencing safely;
• distinguish 2PC, saga, TCC, outbox, and inbox;
• model compensation and partial outcomes;
• protect critical reads from stale projections/replicas;
• test concurrency, partition, replay, and failover;
• and create an internal consistency/concurrency verification backlog.

305. Key Takeaways

1. Consistency is scoped to facts and invariants.
2. Local ACID protects aggregate invariants.
3. Optimistic concurrency prevents stale overwrites.
4. Last-write-wins is not a domain conflict strategy.
5. Reservations are better than long-lived distributed locks for many business claims.
6. Sagas coordinate long-running distributed work.
7. Compensation is not perfect rollback.
8. Eventual consistency requires convergence and reconciliation.
9. Caches and projections must not become hidden authorities.
10. Internal CSG transaction, isolation, and saga patterns must be verified.

306. References

Conceptual baseline:

• ACID transactions, isolation levels, optimistic/pessimistic concurrency, database constraints, and serialization anomalies.
• CAP/PACELC, causal/session consistency, bounded staleness, replication, and multi-region trade-offs.
• Saga orchestration/choreography, TCC, reservations, leases, fencing tokens, and compensation.
• Transactional outbox, inbox/deduplication, CQRS, projections, and reconciliation.
• Domain-Driven Design aggregates, invariants, process managers, and authority boundaries.

These references do not define internal CSG database isolation, locking, saga, reservation, or distributed-transaction implementation.