Situation
On Cash Clearance, after the DynamoDB caching layer cut search latency from 3–5 minutes to under 5 seconds, a second problem surfaced: two users could sit on the same treaty's open transactions and both start marking cleared. Without coordination, you get duplicate clearances — finance lead angry, audit problem, real money out the door twice.
Task
Lead Engineer on a regulated reinsurance workflow with $billions in active treaty exposure. The architecture call was mine. The wrong one would have shipped a correctness bug into a system where customer checks settle against the results.
Action
The conservative answer was a database-level lock or a strict serialisation on Aurora — both legible, both safe, both wrong for the latency profile. The reckless-looking answer was to let the cache hold the concurrency contract: the version token on the cached search snapshot doubles as an optimistic-concurrency check on every write. If the underlying transaction set has shifted since the snapshot, the write fails fast, the user re-runs the search, and the system never lets two users operate on stale data. The hard part was naming what the decision actually was: the DDB cache is no longer a performance optimisation. It is the place we read the truth from for this workflow. That's a real architectural statement and I had to be willing to put it in writing. I walked it through with the data team and the finance owner explicitly, line by line, before committing. If the snapshot semantics were ever wrong, the cache would have to be the place we fixed them — not Aurora.
Result
Zero duplicate clearances in production since cutover, under concurrent load on 100K+ row result sets. The harder lesson: the dangerous call isn't moving the contract — it's moving it without explicitly saying you moved it. Name the new contract or you don't have one.