Fix product recalls with real-time blocking and strong consistency

A recall notice today is just a static page or email—easy to ignore, impossible to enforce. Recalled baby cribs, car seats, and toys continue to be resold because there’s no real-time check at the point of sale. Until now, the system had no way to stop a recalled item from changing hands.

I built SafeState to change that. The concept is simple: when a second-hand item is listed or sold, the marketplace checks SafeState first. If the item is recalled—down to the serial number—the sale is blocked immediately. Only safe units proceed to checkout. The system runs on Next.js and Vercel, with Amazon Aurora DSQL powering the real-time checks.

How strong consistency closes the recall gap

The core challenge isn’t just storing recall data—it’s ensuring every marketplace in every region sees recalled items as unsafe the moment the recall is issued. Any delay between a recall and its enforcement creates a dangerous window where a recalled product could be sold.

Aurora DSQL solves this with its active-active, multi-region architecture and strong consistency guarantees. I set up a peered cluster across us-east-1, us-east-2, and us-west-2, with the latter acting as a witness. A recall written in one region is immediately readable in another. The app includes a live demo page where users can test this behavior themselves.

Forcing conflicts to enforce recall logic

DSQL operates on snapshot isolation with optimistic concurrency control (OCC), which catches write-write conflicts at commit time. But snapshot isolation alone won’t prevent write skew—a situation where a recall and a sale for the same product could both commit without detecting a conflict.

To guarantee collisions, both recall enforcement and sale authorization write to the same row: a safety_guard table that tracks a product’s status and an epoch number. When a transfer is authorized, the system locks the guard row, evaluates active recalls for that unit, and either blocks the sale or completes the transaction.

await client.query("BEGIN")
await client.query("SELECT epoch FROM safety_guard WHERE model_id = $1 FOR UPDATE", [modelId])

# Evaluate active recalls for this unit...

if is_recalled:
    return BLOCKED
else:
    await client.query("INSERT INTO ownership_transfers (...) VALUES (...)")
    await client.query("UPDATE product_instances SET current_owner_id = $1 WHERE id = $2", [buyer, id])
    await client.query("UPDATE safety_guard SET updated_at = now() WHERE model_id = $1", [modelId])
    await client.query("COMMIT")

If a recall commits first, the sale’s commit throws SQLSTATE 40001 (OC000). A retry wrapper catches these conflicts, backs off with jitter, and retries the transaction up to three times. The second attempt reads the recalled state and blocks the sale. This ensures no recalled product ever slips through as safe.

const RETRYABLE = new Set(["40001", "OC000", "OC001"]);

// Retry the entire transaction on conflict

Vercel’s role in a zero-trust recall system

SafeState’s frontend runs on Vercel, but the real magic happens in the backend. Route handlers communicate with DSQL over standard PostgreSQL protocol, and authentication uses short-lived IAM tokens generated per connection with @aws-sdk/dsql-signer. No database passwords are stored in environment variables.

Daily cron jobs pull fresh recall data from the CPSC public API. Meanwhile, an AI model (powered by Claude) scans unstructured second-hand listings—text like "used baby sleeper, works fine"—and matches them to recalls with a confidence score. Low-confidence matches go to a review queue instead of being auto-blocked.

One deployment quirk took an unexpected hour to resolve. Vercel Functions run on AWS Lambda, which reserves AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION as reserved environment variables. These can’t be overridden. The solution was to pass DSQL credentials under different names and inject them directly into the signer.

const creds = process.env.SAFESTATE_AWS_ACCESS_KEY_ID
    ? {
        accessKeyId: process.env.SAFESTATE_AWS_ACCESS_KEY_ID,
        secretAccessKey: process.env.SAFESTATE_AWS_SECRET_ACCESS_KEY
      }
    : undefined;

const signer = new DsqlSigner(
    creds ? { hostname, region, credentials: creds } : { hostname, region }
);

Key lessons for building with DSQL

If your product’s value hinges on correctness under high concurrency, DSQL is the right foundation. Three rules emerged while building SafeState:

• Focus on problems where correctness under concurrency is the core feature, not an afterthought.
• Design conflicting operations to write the same row—this gives DSQL’s OCC something to catch.
• Write the retry-on-40001 wrapper first. You’ll depend on it constantly.

Product recalls should no longer be static PDFs or forgotten webpages. With Aurora DSQL and Vercel, enforcement can happen in real time—preventing unsafe sales before they occur.

The system is live at safestate.vercel.app, and the code is available on GitHub. This project was built for the H0: Hack the Zero Stack hackathon.