allanninal.dev/build

Part 4 of 7 · Warranty registration handler series ~9 min read

How a warranty record gets stored

Once a purchase is verified, the system turns it into a durable fact: how long the cover runs, the day it ends, and a record that can never be quietly created twice. This post is about that write — the term-and-expiry maths, the conditional claim on the serial that guarantees one warranty per unit, and the expiry date indexed so the reminders can find it later.

Key takeaways

  • The store step turns a verified sale into a durable record: the warranty term, the exact expiry date, and the coverage, all computed and written once.
  • The term and expiry are derived from the product’s warranty rule and the purchase date on the order — never typed by anyone.
  • The serial is claimed with a conditional write, so the same unit can never be registered twice even if two submissions race at the same instant.
  • The expiry and reminder dates are indexed on a GSI so the scheduled sweep can find due warranties without scanning the whole table.
  • Only after the record is safely stored does one Bedrock call write the confirmation, explaining the coverage in plain language.

From a verified sale to a durable fact

By the time this step runs, Part 3 has proven the purchase is real, unregistered, and in window, and handed over a store job carrying the verified serial, the sale it matched, and the product line. What’s left is to turn that into a fact the business can rely on for years: a warranty record that says exactly what’s covered, for how long, and until when — written in a way that can never quietly happen twice, and indexed so the reminders can find it long after everyone’s forgotten this particular Tuesday. This is the step where a registration stops being an event and becomes a record.

Two things make that record trustworthy: the dates are computed rather than entered, and the write is guarded so it can only ever create one warranty per serial. Get those right and everything downstream — the confirmation, the reminders, the claim months later — is standing on solid ground.

The term and expiry are computed

A warranty term is a rule about a product, not a number a customer supplies. The settings doc holds those rules per product line, and they’re often layered: Cadence e-bikes, from Part 1, cover the frame for five years and the motor and battery for two; Halewood’s drills are three years on the tool and one on the battery; a Bramble & Moss mattress is a flat ten years. The store step reads the rule for this product line and applies it to the purchase date from the order record — the verified one, not anything the buyer typed — to compute the exact expiry date, or dates, for each covered component. A two-year motor warranty on a bike sold on 12 July 2026 expires on 12 July 2028; the maths is plain calendar arithmetic, done once, in Python.

Computing the dates rather than storing a duration matters because a duration is a question and a date is an answer. “Two years” still needs a start date and a calendar to mean anything; “expires 12 July 2028” is unambiguous, sortable, and something the reminder sweep can query directly. So the record stores the resolved dates: when each component’s cover ends, and the dates the reminders should fire. If the warranty rule ever changes, existing records keep the expiry they were sold with, because it’s baked into the record at registration rather than recomputed from a rule that might have moved.

Claimed exactly once

The record is written to the warranties table keyed by the serial, and the write is a conditional one: create this item only if no item for this serial already exists. This is the permanent enforcement of the “one serial, one warranty” rule that the whole system rests on. Part 2’s dedup window and Part 3’s duplicate check are early, friendly guards that give a clear answer; this conditional write is the last, absolute one. If two submissions for the same serial somehow reach this step at the same instant — a double-tap that beat the dedup window, a retry racing the original — only one conditional write can succeed. The other fails cleanly, is recognised as a duplicate, and the buyer is simply told the product is already registered. There is no window, however small, in which a serial can end up with two warranties.

Because the write is idempotent in this way, the whole pipeline behind it can safely retry. If the store Lambda crashes after computing the dates but before confirming, the job comes back off the queue and runs again; the second attempt either completes the write or discovers the record it already made. That’s what lets the system lean on SQS and at-least-once delivery without ever double-registering — the conditional write is the single point where “exactly once” is actually decided.

Storing a warranty: compute term and expiry, claim the serial with a conditional write, index the dates, then confirm On the left, a box “Store job from queue” lists the verified serial, the matched sale with its purchase date, and the product line. An arrow leads into a box “Store Lambda” inside a dotted AWS account container. The store Lambda first reads a “Warranty rules” box holding the term per product line, then computes the term and exact expiry dates from the purchase date. An arrow goes to a decision box “Conditional write on serial — create only if none exists”, writing to a DynamoDB warranties table keyed by serial. If the condition fails because a record already exists, an arrow exits to a small “Already registered” box. If it succeeds, the record is written with the coverage, the expiry dates, and the reminder dates, and those dates populate a GSI labelled reminder index so the sweep can find them. From the successful write an arrow goes to a box “Enqueue confirm”, which leads to a box “Bedrock Haiku 4.5” that writes the plain-language confirmation, sent out via SES or SNS. A note reads: the dates are computed from the verified purchase, the serial is claimed exactly once, and only a stored record triggers the confirmation. Store job verified serial matched sale + date product line AWS account Store Lambda compute term + expiry Warranty rules term per product read Conditional write on serial create only if none exists DynamoDB warranties PK serial GSI: reminder index by due date Already registered exists Enqueue confirm after the write stored Bedrock Haiku 4.5 plain-language confirmation → SES / SNS Computed, claimed once, then confirmed.
Fig 4. Storing a warranty. The store step reads the warranty rule, computes the term and exact expiry from the verified purchase date, then claims the serial with a conditional write — only one can win. The record carries the coverage and the reminder dates, indexed on a GSI, and only a successful write triggers the confirmation.

Indexed so the reminders can find it

A warranty record isn’t much use to the reminder system if the only way to find the ones due next week is to read every record the business has ever created. So alongside the coverage and expiry, the store step writes the reminder dates onto a global secondary index — a second way into the same table, keyed by when a warranty next needs attention rather than by which serial it is. The maintenance nudge for the Cadence bike (say, five months after purchase) and the pre-expiry heads-up (a month before the motor cover ends) each land in that index under their due date. Part 5’s sweep queries the index for “everything due today” and gets a short, exact list, no matter how many warranties are stored in total. A time-to-live attribute is also set on the record’s housekeeping markers, so transient state expires itself and the table stays lean; the warranty record proper is kept as long as the cover runs, and beyond, so a claim can always be looked up.

Only then, the confirmation

The buyer’s confirmation is the last thing to happen, and deliberately so: nothing is sent until the record is safely stored, because a “you’re registered” message that isn’t backed by a saved warranty is a lie waiting to be found out. Once the write succeeds, a confirm job is enqueued and one Bedrock Haiku 4.5 call — the only place a model runs in the whole system — turns the stored coverage into a warm, plain-language message. It’s handed only the facts from the record: the product, what’s covered, and the expiry dates it just computed. It writes something like “You’re all set — your mattress is guaranteed for 10 years, until 4 August 2036,” not a wall of terms and conditions. The model phrases the coverage; it never decides what the coverage is, and the dates in the message are the ones the code computed, not numbers the model invented. As in any well-behaved use of a model here, the draft is checked for the right dates and a sane length, and a plain fixed template stands ready if the model is slow or drifts, so the confirmation is always correct and always on time.

Design rules that shaped the store step

  • Compute dates, don’t store durations. The exact expiry is derived from the verified purchase date and baked into the record.
  • One conditional write decides everything. The serial is claimed only if unclaimed, so “one warranty per unit” holds even under a race.
  • Idempotent by design. Because the write is conditional, the whole pipeline can retry safely without ever double-registering.
  • Index by due date. Reminder dates go on a GSI so the sweep finds what’s due with a query, not a full-table scan.
  • Store first, then say so. The confirmation is only sent after the record is written — no message without a warranty behind it.
  • The model phrases, the code decides. Bedrock explains the coverage in plain words; the dates and terms are the ones computed, never invented.
All posts