What is a back-in-stock notifier?

It is a small serverless system that remembers who asked to be told when a sold-out item returns. When a shopper taps “notify me” on an out-of-stock product, the system records the request against that exact SKU and adds them to a per-item waiting list. When the store’s inventory system reports that SKU back above a threshold, the system texts or emails the waiting list in the order they joined — each message carrying a short-lived reserve link — and stops as soon as it has notified as many people as there are units. A restock stops being a scramble and becomes a fair, orderly queue.

How much does it cost to run?

About $2.10/month at a typical independent-shop volume of roughly 120 notify-me requests a month across its restocks. There is no always-on compute, so the bill is almost entirely usage-priced — the outbound SMS and one small Bedrock call per restock are the main lines, and the only real fixed cost is Secrets Manager for the webhook and messaging keys. At ten times the volume (around 1,200 requests a month) the bill lands near $13, because the fixed lines don’t move.

Which AWS services does it use?

Lambda (Python 3.14, arm64) behind Function URLs for the notify-me capture, the store’s inventory webhook, and the reserve-link redirect, DynamoDB on-demand for requests and a per-SKU waitlist, EventBridge Scheduler for the reservation-expiry sweep, SNS for outbound SMS and SES for email, SQS with a dead-letter queue, Secrets Manager for the keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to phrase each notice. No API Gateway, no NAT Gateway, no always-on compute. One region, eu-west-2.

How fast does the notice go out?

Within seconds of the store’s inventory system reporting the SKU back in stock. The webhook fires the moment the stock level crosses the threshold; the system verifies it, confirms it’s a genuine new restock rather than a duplicate, works out how many units came in, and messages that many people from the front of the queue — each with a reserve link that’s live for a short window. If a link isn’t used before it expires, a scheduled sweep releases that unit to the next person waiting, so the queue keeps moving without anyone jumping it.

Only to write the wording. Bedrock’s Claude Haiku 4.5 fires once per restock to compose a short notice in the store’s voice, and it is handed only the facts it may use — the product name, the store name, and a link placeholder — with instructions to use only those. The trigger (the inventory webhook), the queue order, the cap to available quantity, the once-per-restock dedup, the opt-out check, and the reservation holds are all deterministic Python. The model never decides who to notify, how many, or in what order.

Can it oversell, or let someone jump the queue?

No. It caps each restock’s batch to the number of units that actually came in, so it never invites more people than there is stock, and each reserve link holds a unit with a conditional write that can’t take the count below zero. People are notified strictly in the order they joined the list — oldest request first — and each is notified at most once per restock. If someone doesn’t use their reserve link before it expires, the unit is returned to the pool and offered to the next person in line, never to a latecomer ahead of them.

Series · 7 parts Published July 2, 2026

Back-in-stock notifier

A shopper lands on a sold-out product, taps “notify me”, and joins a queue no one usually manages well — so the stock quietly comes back, a few people who happened to check that morning grab it, and everyone who actually asked to be told never hears a thing. This is the design of a small serverless system that closes that gap: it captures each notify-me request against the exact SKU, watches the store’s inventory feed for that item coming back above a threshold, and then texts or emails the waiting list in the order they joined — each message carrying a short-lived reserve link so the first people to respond actually get the stock. It notifies each person once per restock, honours opt-out, caps the batch to the quantity that came in so it never oversells, and expires stale requests and unclaimed holds so the line keeps moving. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A back-in-stock notifier on AWS for a few dollars a month

The whole system on one page — the notify-me capture, restock detection from the inventory webhook, a FIFO notifier capped to the units that came in, short-lived reserve links, and an expiry sweep — plus the guarantee that it notifies in order and never oversells.
02

How a back-in-stock request gets captured

How a “notify me” tap becomes a place in the queue — the capture Function URL, validating the request, one active request per person per SKU, the opt-out check, and appending it to the per-SKU waiting list in join order.
03

How a restock gets detected

How a restock is detected — the store’s inventory webhook, verifying it, spotting the genuine below-to-above-threshold transition, working out how many units came in, and firing exactly one notify batch per restock without flapping or double-firing.
04

How the waiting list gets notified

How the waiting list gets notified — reading the per-SKU queue oldest-first, capping the batch to the units available so it never oversells, one Bedrock call to phrase the notice, a personalised reserve link each, and marking every recipient notified once per restock.
05

How a reservation gets held

How a reservation is held — the reserve link that holds a unit with a conditional write that can’t oversell, the short window it’s live for, and the EventBridge Scheduler sweep that expires unclaimed holds and offers the freed unit to the next person in line.
06

What the back-in-stock notifier costs

A line-by-line monthly cost at about $2.10 for roughly 120 notify-me requests, where the money actually goes (outbound SMS and one Bedrock call per restock), and what the bill looks like at ten times the volume.
07

Engineering reference: the back-in-stock notifier architecture

The same system drawn for engineers — the Lambda inventory, the three Function URLs, the SQS-buffered notifier, the DynamoDB tables and key schema, the reservation holds and TTL, the expiry schedule, IAM scope, the Bedrock model id, and the region.

What is a back-in-stock notifier?: It is a small serverless system that remembers who asked to be told when a sold-out item returns. When a shopper taps “notify me” on an out-of-stock product, the system records the request against that exact SKU and adds them to a per-item waiting list. When the store’s inventory system reports that SKU back above a threshold, the system texts or emails the waiting list in the order they joined — each message carrying a short-lived reserve link — and stops as soon as it has notified as many people as there are units. A restock stops being a scramble and becomes a fair, orderly queue.
How much does it cost to run?: About $2.10/month at a typical independent-shop volume of roughly 120 notify-me requests a month across its restocks. There is no always-on compute, so the bill is almost entirely usage-priced — the outbound SMS and one small Bedrock call per restock are the main lines, and the only real fixed cost is Secrets Manager for the webhook and messaging keys. At ten times the volume (around 1,200 requests a month) the bill lands near $13, because the fixed lines don’t move.
Which AWS services does it use?: Lambda (Python 3.14, arm64) behind Function URLs for the notify-me capture, the store’s inventory webhook, and the reserve-link redirect, DynamoDB on-demand for requests and a per-SKU waitlist, EventBridge Scheduler for the reservation-expiry sweep, SNS for outbound SMS and SES for email, SQS with a dead-letter queue, Secrets Manager for the keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to phrase each notice. No API Gateway, no NAT Gateway, no always-on compute. One region, eu-west-2.
How fast does the notice go out?: Within seconds of the store’s inventory system reporting the SKU back in stock. The webhook fires the moment the stock level crosses the threshold; the system verifies it, confirms it’s a genuine new restock rather than a duplicate, works out how many units came in, and messages that many people from the front of the queue — each with a reserve link that’s live for a short window. If a link isn’t used before it expires, a scheduled sweep releases that unit to the next person waiting, so the queue keeps moving without anyone jumping it.
Does it use AI?: Only to write the wording. Bedrock’s Claude Haiku 4.5 fires once per restock to compose a short notice in the store’s voice, and it is handed only the facts it may use — the product name, the store name, and a link placeholder — with instructions to use only those. The trigger (the inventory webhook), the queue order, the cap to available quantity, the once-per-restock dedup, the opt-out check, and the reservation holds are all deterministic Python. The model never decides who to notify, how many, or in what order.
Can it oversell, or let someone jump the queue?: No. It caps each restock’s batch to the number of units that actually came in, so it never invites more people than there is stock, and each reserve link holds a unit with a conditional write that can’t take the count below zero. People are notified strictly in the order they joined the list — oldest request first — and each is notified at most once per restock. If someone doesn’t use their reserve link before it expires, the unit is returned to the pool and offered to the next person in line, never to a latecomer ahead of them.

All posts

Frequently asked questions

Other series