In this chapter
We'll build a real conditional write that stops a duplicate request from silently overwriting the original, and meet DynamoDB's transactions and consistency models.
The Problem in Real Life
A seller's registration request goes out over a flaky connection during a promo signup rush. The phone shows a spinner, the seller taps "Submit" again, and now two nearly-identical PutItem calls are on their way for the exact same seller id — one with a typo in the shop name the seller caught and fixed between taps, one without.
Without anything stopping it, whichever request lands second just silently overwrites the first. No error, no warning — just whichever arrived last, quietly declared correct.
I don't want the database to just believe whichever write shows up last.
Sarah
Silent Overwrite vs. A Promise the Database Enforces
An unconditional write silently overwrites
Whichever write lands last just wins — no error, no warning, nothing to notice.
A conditional write enforces a real promise
attribute_not_exists refuses the write outright, atomically, if the condition isn't met.
Transactions extend the guarantee across items
Multiple writes succeed or fail together — all-or-nothing, the same shape as a single conditional write.
Eventually vs. strongly consistent reads
The CAP-theorem trade-off, made real and choosable per read — fast-but-possibly-a-moment-behind, or guaranteed current.
Conditional Writes, Transactions & Consistency
A conditional write lets GreenMart attach a real requirement to a write, checked atomically as part of the write itself — not as a separate read beforehand, which would leave the exact same race-condition gap the Redis Act's distributed lock chapter already covered.
attribute_not_exists means "only write this if no item with this exact key already exists." The first PutItem succeeds. The second — the accidental duplicate — fails outright, atomically, instead of silently overwriting the first with whatever arrived second. This is DynamoDB's real conditional-write mechanism, simplified to its most common case.
PutItem("Sellers", { sellerId: "sel-09", shopName: "Fresh Finds" }, { condition: "attribute_not_exists" })PutItem("Sellers", { sellerId: "sel-09", shopName: "Fresh Finds Co." }, { condition: "attribute_not_exists" })
A failed conditional check is a genuinely correct, expected outcome here, not a bug in the script — it's exactly what's supposed to happen the second time.
This is what atomic operations mean in DynamoDB, the same underlying idea Redis's DECR and SET ... NX already taught: the check and the write happen as one indivisible step, so there's never a window for a second request to slip through unnoticed. A transaction (DynamoDB's TransactWriteItems) extends the same all-or-nothing guarantee across multiple items at once — say, deducting stock from one item and creating an order record in another, where both have to succeed together or neither happens at all. This simulator doesn't implement multi-item transactions, but the guarantee is real: DynamoDB will roll back every write in the group if even one condition in it fails.
One more promise worth being precise about: consistency models. By default, a DynamoDB read is eventually consistent — extremely fast, but it might, very briefly, return data that's a moment behind the most recent write, the same trade-off Act 1's CAP theorem chapter first introduced in the abstract. Passing consistentRead: true asks for a strongly consistent read instead — guaranteed to reflect every write that's completed before it, at some extra cost in latency. This simulator has no real replicas and no real lag to demonstrate, so both options return identical, fully up-to-date results here — the syntax is real DynamoDB, shown for what it looks like, not something this Playground can meaningfully distinguish.
Key Takeaway
A conditional write turns "I hope this doesn't get overwritten" into a promise the database actually enforces, atomically, as part of the write itself — the same shape as every other atomic guarantee this course has built.
Why This Matters
Every write GreenMart makes to a table that could plausibly receive a duplicate or a stale overwrite is a candidate for a conditional write — not a rare edge case, but the default habit worth having, the same way Redis's atomic operations became a habit rather than a special case reached for occasionally.
GreenMart's writes can now enforce real promises instead of hoping nothing races them. None of this changes what it actually costs to run this table at scale, though — and that's exactly what the next chapter is about.