Running a DPP Resolver

Building a resolver is straightforward engineering. Operating one for decades, for products you can no longer change, is a different proposition and it is where passport programmes underestimate the commitment.

The physical constraint

Everything about resolver operations follows from one fact: the identifier is printed, moulded or etched onto an object that is already in the world.

This makes several conventional practices unavailable. Versioning in the URL path, restructuring during a site redesign, and moving to a new domain after a rebrand are all things a normal web estate does routinely and a resolver cannot do at all.

Availability is a compliance property

If a regulation requires that product information be accessible through a data carrier, information that is not accessible is a compliance gap rather than a service degradation.

That reframes an outage. A retailer whose website is down loses sales for an hour; a manufacturer whose resolver is down has, for that hour, every product on every shelf failing to provide legally required information.

The practical consequence is that resolver hosting deserves the treatment given to payment systems rather than to marketing sites, including independent monitoring, tested failover and an actual understanding of every dependency in the path.

Traffic behaves unusually

Resolver load does not resemble the traffic patterns most enterprise systems are sized for, because it is driven by physical events rather than by digital campaigns.

The fourth row is the one that catches capacity planning out. Load grows with the total population of products in the field rather than with current sales, so it keeps rising even if sales are flat and continues after a product is discontinued.

Caching, and what it breaks

Aggressive caching is the obvious answer to unpredictable public traffic, and it interacts badly with exactly the attributes that most need to be current.

The last node is the one to design around first. A cached response showing a product as not recalled, hours after a recall was issued, is the single worst failure mode a resolver has, and it is entirely a caching design decision rather than an unlucky accident.

Retention outlives everything

Records must remain available and reconstructible for a period set by regulation, which for durable goods runs well beyond the life of any system currently holding them.

• System migrations — records must survive each one with history intact.
• Vendor changes — the obligation does not transfer away with a contract.
• Corporate change — acquisitions and divestments have to carry the records.
• Product discontinuation — the obligation continues after the product line ends.
• Company failure — an unresolved question the sector has not answered well.

The last point is genuinely unresolved. When a manufacturer ceases to exist, its resolver stops and every product it ever made loses its record, which is a systemic gap that individual programmes cannot fix on their own.

Practical arrangements that hold up

A few decisions substantially reduce the long-term operational risk, and all are much cheaper to take at the outset than to retrofit.

Use a dedicated subdomain that no marketing team will ever restructure. Keep the identifier scheme free of anything that could change — no version numbers, no product line names, no country codes that might be reorganised. Separate the resolver from the rendering layer so a redesign never touches resolution.

Test the full export of records including history at least annually, because the ability to move to a different system is what makes the multi-decade obligation survivable, and an export that has never been tested is an assumption rather than a capability.

Monitor from outside your own network, from the regions where products are actually sold. A resolver that responds correctly to internal checks and fails for a consumer in another member state is a failure nobody inside the organisation will notice until a customer complains.

And keep an inventory of every identifier scheme in use, including any inherited through acquisition. Programmes that cannot enumerate what they have already marked cannot assess their own exposure, and that inventory is invariably harder to reconstruct later than to maintain from the start.