Postcode Lookup and the Cache
Postcode lookup answers one question — where is this postcode, roughly — and one derived from it: how far apart are these two points.
Where to find it
Architect Panel → Integration & Connections:
- Postcode Lookup — the console — cache size, hit rate, recent misses, clear and warm
Architect Panel → Configuration:
- Site Settings — Look postcodes up, and the provider and cache settings
Architect Panel → Layout & Pages:
- Browse Views — the feature that consumes it
What it is not
It is not a mapping library, an address validator or a routing engine. It does not know what a road is, so every distance it returns is a straight line.
That is worth saying plainly to visitors as well as to yourself. A browse view sorted "nearest first" is sorted by crow-flies distance — which is the right ordering for almost every catalogue and is not the same as drive time. Somewhere across an estuary can be two miles away and forty minutes' drive.
The cache is the point of the feature
A browse view returns the whole table and the front end trims it, so ordering a catalogue by distance means knowing where every row is. Geocoding that on each request would be thousands of outbound calls per page view.
The cache makes it viable, and the key detail is what it is keyed on: the postcode, not the record. A hundred records in the same town share one cache row and one lookup, and the second page view makes no network calls at all.
Unresolvable postcodes are cached too
A postcode that cannot be found is recorded as a negative result rather than simply not stored.
Without that, one bad postcode in a catalogue would re-hit the provider on every single refresh, for ever — and the provider is the one part of this that can be slow or cost money. Negative caching is what stops a single typo becoming a permanent tax on every page view.
Two ages, deliberately different
- Found postcodes are re-checked after a year by default. Postcode coordinates barely move.
- Unknown postcodes are retried after a month, because a genuinely new postcode will eventually start resolving.
It ships switched off
Look postcodes up is off by default, so no installation makes outbound geocoding calls until somebody decides it should. Nothing about a browse view changes until you enable it.
The console
Architect Panel → Integration & Connections → Postcode Lookup shows the cache size and hit rate, the recent misses, and gives you a clear and a warm action.
The recent misses list is the useful one — a run of failures against the same malformed pattern usually means a data quality problem in the source field rather than a provider issue.
Coordinates you already have cost nothing
A Geolocation field already holds coordinates, so records using one need no lookup and no cache entry. Similarly, when a visitor uses their browser's own location, those coordinates are passed straight through rather than being converted back into a postcode and out again.
Worked example
A directory of 4,000 venues across 900 distinct postcodes warms in one pass. The cache holds 900 rows, not 4,000, and a visitor sorting by distance triggers no outbound calls at all. Eleven postcodes fail — all in one imported batch with a transposed character — and appear together in the recent misses list.
Recommendations
- Describe it as straight-line distance wherever visitors see it.
- Warm the cache before the first visitor sorts a large catalogue.
- Read the recent misses as a data quality signal.
- Leave the cache ages alone unless you have a reason.