Building Digital Product Passports: Architecture Decisions That Scale

When we set out to build Veribl's Digital Product Passport infrastructure, we faced a fundamental question: how do you design a system that can handle millions of unique product identities while remaining fast, reliable, and compliant with evolving regulations?

This post walks through the key architecture decisions we made — and the trade-offs behind them.

The Scale Challenge

Consider a mid-size fashion brand with 5,000 SKUs, each produced in quantities of 10,000 units per season. That's 50 million unique product passports per year, each requiring:

• A unique, persistent identifier
• Structured data conforming to ESPR schemas
• A scannable data carrier (QR code) linking to the passport
• Sub-200ms response times for consumer-facing scans
• Full audit trails for regulatory compliance

Multiply this across thousands of brands and you start to see the infrastructure challenge.

Data Model

Product vs. Passport

We made an early decision to separate the product template from the passport instance. A product template defines the shared attributes of a SKU — material composition, manufacturing process, sustainability metrics. A passport instance represents a specific unit, adding serialization, batch data, and scan history.

interface ProductTemplate {
  id: string
  brand_id: string
  name: string
  category: string
  materials: MaterialComposition[]
  carbon_footprint: CarbonData
  repairability_score: number
  certifications: Certification[]
}
 
interface PassportInstance {
  id: string
  template_id: string
  serial_number: string
  batch: string
  manufactured_at: string
  data_carrier_url: string
  scan_count: number
}

This separation means updating a product's sustainability data propagates to all its passports instantly, without rewriting millions of records.

Schema Versioning

ESPR requirements will evolve. We built schema versioning into the data model from day one. Every passport records which schema version it was created under, and we maintain backward compatibility across versions.

API Design

Our API follows three principles:

1. Reads are fast — passport lookups are the most frequent operation (every QR scan hits the API), so we optimize aggressively for read performance
2. Writes are reliable — passport creation and updates go through a queue-based pipeline with exactly-once semantics
3. Everything is auditable — every mutation creates an immutable audit log entry

Scan Endpoint

The scan endpoint is the most performance-critical path in the system. When a consumer scans a QR code, we need to:

1. Resolve the identifier to a passport
2. Merge template data with instance data
3. Apply any locale-specific formatting
4. Log the scan event for analytics
5. Return the complete passport — all within 150ms

We achieve this with an edge-cached read path. Passport data is pre-computed and cached at CDN edge nodes, so most scans never hit the origin server.

QR Code Generation

Each passport needs a unique, scannable QR code. We generate these as SVGs with embedded error correction, optimized for both digital display and physical printing at various sizes.

Key considerations:

• Minimum size: 15mm × 15mm for reliable scanning
• Error correction: Level M (15% recovery) for printed labels, Level L for digital
• URL structure: Short, deterministic URLs that resolve to the passport viewer

Analytics Pipeline

Every scan generates an event that flows through our analytics pipeline:

1. Capture — scan events are ingested via a lightweight endpoint
2. Enrich — we add geolocation, device type, and temporal data
3. Store — events land in a time-series store for real-time dashboards
4. Aggregate — nightly jobs compute brand-level metrics

This gives brands real-time visibility into how consumers interact with their products.

Lessons Learned

Start with the read path. We initially built writes first and optimized reads later. In hindsight, we should have designed the read path from the start — it's where all the performance pressure lives.

Schema flexibility matters more than you think. ESPR requirements have already been amended twice since initial publication. Building rigid schemas would have required painful migrations.

QR codes are a physical product. We underestimated the complexity of printing QR codes at scale. Factors like label material, print resolution, and environmental conditions all affect scannability.

The best DPP architecture is invisible to the consumer. They scan a code and get instant, rich product information. Everything else — the data pipelines, caching layers, compliance validation — should just work.

What's Next

We're currently working on federated DPP resolution — allowing passports from different providers to interoperate seamlessly. This is critical for supply chains where multiple brands contribute data to a single product's passport.

The DPP ecosystem is still young, but the architectural decisions made today will determine how well the infrastructure scales over the next decade.