Scalability
Two workloads that have nothing in common
Reads follow public scans: bursty, cacheable, and impossible to forecast. Writes follow supply chain events: steady, machine-driven, append-only. Sizing them as one system is how passport platforms fall over.
- Reads
- Bursty, cacheable
- Writes
- Steady, append-only
- Scaled
- Independently
Definition
What determines the scale of a Digital Product Passport platform?
Two independent workloads. Read volume follows public scans, which are bursty and unpredictable, and is largely cacheable because the public tier is identical for every caller. Write volume follows supply chain events, which are steady and machine-generated. They are sized and scaled separately.
The consequence for planning is that catalogue size is a poor predictor of either. Event volume tracks how much your products move; read volume tracks how much attention they receive.
Load shape
Why one system cannot serve both
| Characteristic | Passport reads | Event writes |
|---|---|---|
| Triggered by | A person scanning a product | A machine recording a step |
| Shape | Bursty and unpredictable | Steady and forecastable |
| Cacheable | The public tier, almost entirely | Not at all — every write is new |
| Latency need | A person is waiting | A queue can absorb it |
| Grows with | Attention and campaign activity | Physical movement of goods |
| Failure impact | A consumer sees nothing | History develops a gap |
Design
What follows from that split
Cached public tier
The response every anonymous caller gets is identical, so it is served from cache.
Per-request restricted tiers
Credential-dependent responses are resolved live — the expensive path, taken least often.
Independent scaling
A scan burst cannot delay ingestion; a bulk import cannot slow a resolver.
Append-only event log
Writes never contend with updates, because events are added rather than modified.
Bulk ingestion
Historic event backfill runs on its own path, not through the live write route.
Query by object
History is retrieved by identifier — the access pattern audits and recalls actually use.
Answers
Frequently asked questions
What actually drives load on a passport platform?
Two unrelated things. Reads follow scans, which are public, bursty and unpredictable — a product featured in a broadcast can produce more reads in an hour than in the preceding year. Writes follow supply chain events, which are machine-generated and steady. Sizing for one tells you nothing about the other.
Why are reads and writes separate systems?
Because a scan burst must not be able to delay event ingestion, and a bulk event import must not slow the resolver a consumer is waiting on. The resolver serves a mostly-static, cacheable response; the event store is an append-heavy log queried by object identity. Those are different problems.
Does event volume grow with the number of products?
It grows with movement, not with catalogue size. A pallet moving through a distribution network generates more events than a thousand items sitting in a warehouse. Organisations that size on SKU count are usually surprised in both directions.
How is a passport read kept fast?
The public tier is cacheable, because it is the same response for every caller and changes rarely. Restricted tiers are resolved per request, since the answer depends on the credential presented — so the expensive path is the one taken least often, which is the right way round.
What are your availability commitments?
They belong in a service agreement rather than on a marketing page, and we will put them in writing during procurement. We deliberately do not publish an availability figure here: a number with no contract and no status page behind it is not a commitment, and an engineer evaluating us will treat it as noise.
Next step
Bring your expected volumes
Catalogue size, movement frequency and the campaign peak you are most worried about. We will size against those rather than against a headline number.