Skip to content

Series · 7 parts Published August 6, 2026

Address verifier

A small system that checks a delivery address as it is entered, suggests a correction where one is obvious, and lets the customer proceed either way. It also re-checks the addresses already in the database, because most of the failures are already there. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.

  1. 01

    An address verifier on AWS for a few dollars a month

    The whole system on one page — a checker, a suggester and a background sweep — built on the observation that the reference file is authoritative and not complete.

  2. 02

    How an address gets checked

    What normalisation has to do before a lookup, the four outcomes a check produces, why a boolean is not enough, and the caching that keeps this affordable.

  3. 03

    How a correction gets suggested

    Why one suggestion beats a list, the threshold for offering anything at all, why the specific difference must be visible, and how a declined suggestion is handled.

  4. 04

    How an unverified address is handled

    What an unverified flag is for, who sees it and when, the single intervention worth making after the order, and the addresses that are permanently unverifiable.

  5. 05

    How stored addresses get swept

    Why the stored addresses matter more than the ones being typed, how to sweep them without contacting anybody out of the blue, and the numbers worth watching.

  6. 06

    What the address verifier costs

    About $45 a month. One Bedrock read per lookup is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.

  7. 07

    Engineering reference: the address verifier architecture

    Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.

What is an address verifier?
A small serverless system that checks an address against a postal reference file as it is entered, suggests a correction where one is clear, and records what the customer chose. It never blocks a customer from proceeding.
Why not just reject bad addresses?
Because the reference file is not complete. New builds, sub-divided properties, farms and rural addresses are routinely absent, and rejecting them turns a delivery risk into a lost order. Suggesting beats blocking every time.
Does it fix addresses automatically?
Only formatting — capitalisation, a missing postcode space. Anything that changes what the address means is offered as a suggestion the customer accepts or declines.
What about the addresses already in the database?
Those are where most failed deliveries come from, and they are checked in the background at a slow rate. A customer whose stored address no longer verifies is asked at their next order rather than being contacted out of the blue.
What does it cost to run?
A few dollars a month plus the reference lookups, which are the only third-party charge. See part six.
All posts