Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Address verifier series ~5 min read

How an address gets checked

Most of the work in checking an address happens before the lookup, and most of the value is in refusing to collapse the answer into a yes or a no.

Key takeaways

  • Normalise case, spacing, abbreviations and field order before any lookup.
  • Four outcomes: exact, formatting-only difference, near-match, and not found.
  • Not found is not invalid. The distinction is the whole system.
  • Cache by normalised address; the same addresses recur constantly.
  • A lookup failure is not a validation failure and must never block anything.

Normalise first

typed        14 chestnut rd, ashford, kent, tn248ql

normalised   line1:     14 Chestnut Road
             town:      Ashford
             county:    Kent          (dropped for lookup)
             postcode:  TN24 8QL

changes      case, ’rd’ expanded, postcode spaced,
             county ignored (it is not part of the identity)

The county line is worth noting. In many postal systems it is decorative — the postcode identifies the delivery point completely — and including it in a lookup produces misses when somebody writes a historic county name. Dropping it for the lookup and preserving it in what is stored is the right handling.

Four outcomes

How a normalised address is checked against the reference fileA vertical chain of five steps entered by a box labelled A normalised address, ready to look up. Step one asks whether it is in the cache in its normalised form, since addresses recur; a hit exits to Reuse with no charge. Step two looks it up with one reference call; an error exits to Lookup failed, which proceeds and marks the address unchecked. Step three asks whether it is an exact match; if so it exits to Verified and tidies formatting silently. Step four asks whether there is one close match, a single obvious candidate; if so it exits to Suggest it with the difference shown. Step five is Not found, which proceeds and marks the address unverified. A note says two of the five exits proceed silently and none of them stops the customer.AWS ACCOUNTA normalised addressready to look upIn the cache?normalised formLookup cacheaddresses recurReuseno chargeyesLook it upone reference callLookup failedproceed, mark uncheckederrorExact match?Verifiedtidy formatting silentlyyesOne close match?a single obvious candidateSuggest itwith the difference shownyesNot foundproceed, mark unverifiedTwo of the five exits proceed silently. None of them stops the customer.
Fig 1. How a check runs and where it can end. The lookup-failed path is worth building explicitly: a third-party outage must not become a checkout outage.
  • Database
  • App integration
  • Machine learning
  • Management
  • Analytics

Not found is not invalid

This is the distinction the whole system rests on and the one a boolean destroys. An address the reference file does not contain might be wrong, and might be a house built last year, a converted barn, a flat above a shop that has never been separately registered, or an address written the way the occupant writes it rather than the way the file records it.

Storing four outcomes rather than two means the warehouse can treat an unverified address differently from a verified one without anybody having been refused, and it means the background sweep can distinguish addresses worth asking about from addresses that simply are not in the file.

Lookup failure is a fifth case

The reference service will occasionally be slow or unavailable, and the correct behaviour is completely uncontroversial: proceed, record the address as unchecked, and let the sweep pick it up later. A checkout that fails because a validation API timed out is a self-inflicted outage, and it is a surprisingly common one.

Caching

Why caching address lookups is unusually effectiveA horizontal row of five boxes. Normalised key: not the raw string. Same address again: from repeat customers. Cache hit: with no charge. Typical hit rate: sixty to eighty per cent. Expire slowly: because addresses barely change. A note says the same addresses recur constantly, from repeat customers, households and offices.WHY CACHING WORKS SO WELL HERENormalised keynot the raw stringSame address againrepeat customersCache hitno chargeTypical hit rate60-80%Expire slowlyaddresses barely changeThe same addresses recur constantly: repeat customers, households, and offices.
Fig 2. Why an address cache is unusually effective. Addresses recur far more than most lookup keys and they change almost never.
  • Machine learning
  • Security & identity
  • Management
  • Analytics

Keying the cache on the normalised address rather than the raw string is what produces the high hit rate: three customers typing the same address three different ways all hit one cache entry. Keying on the raw string would produce a hit rate near zero and pay for the same lookup repeatedly.

A twelve-month expiry is generous and appropriate. Addresses do change — renumbering, postcode boundary changes — but rarely enough that a year-old cached answer is almost always still right, and the sweep in Part 5 catches the ones that are not.

Next: making a suggestion.

All posts