A design-collaboration SaaS at Canva's scale licenses stock photography and fonts on a per-use royalty. Exports have grown fivefold in 2026 while royalty reporting is still derived from the asset CDN's request logs, and the vendor's audit says the reported numbers no longer match usage. Which change fixes reporting without changing what users can do?
Show the full answer Hide the answer
The deciding property
The billable event is a licence use. A CDN request is a delivery. They were close enough to each other when the product was small and one delivery meant one use. Growth broke the correspondence in both directions: caches, prefetch, retries, thumbnail pipelines and preview renders create requests without creating a use, while a cached or client-stored asset creates a use without creating a request. Once a cache sits anywhere in the path the two counts cannot be reconciled, because the cache is designed to remove exactly the evidence the meter depends on.
The general rule this teaches: meter the event the contract charges for, at the point in the system where that event is decided. Not where bytes move, because bytes move for reasons the contract does not care about.
Why the commit point
Saving or exporting a design is where the licence obligation is created, it is idempotent per design version so it does not double-count a retried export, and it is unaffected by every caching and delivery change made downstream. It also produces the record an audit needs: which asset, in which design, for which customer, at which time. The same event stream answers the questions finance and product both ask, which is why this is usually cheaper than it looks.
Why the other options fail
- Adding a cache to reduce origin requests. This reduces the reported count, so the discrepancy gets worse in the direction that matters. Under-reporting a royalty is a contractual exposure, and it is discovered by an audit rather than by a dashboard. It is a real mistake because the same change is correct for infrastructure cost, so it reads as a saving.
- Moving to a per-seat licence. This changes the product's economics and what the vendor's terms allow, which the stem rules out, and it swaps one metering problem for another: seat definitions in media licences are narrow, and a collaboration product's seat count is itself disputed. It can be the right long-term answer and it is not a reporting fix.
- Sampling the logs at 1 in 100. Royalty reporting is an accounting obligation with an audit attached. A 1% sample has an error band no auditor accepts, and the error is not even symmetric, because popular assets and long-tail assets have very different cache hit rates, so the sample is biased towards the assets that are cheapest to report.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| The contract charges per delivery or per gigabyte | The CDN log | The meter now matches the billable event |
| Royalties become flat-rate per period | Neither | There is nothing usage-linked left to meter |
| Assets are bought outright | Neither | The obligation ends at purchase |
| A second vendor is added with different terms | Event stream with a per-vendor rule layer | One meter, several billing rules |
When this is the wrong answer
For a small library you own outright, or one vendor on a flat annual fee, do not build a metering pipeline. It is a durable piece of infrastructure with its own reconciliation, retention and correctness obligations. The exercise pays when the royalty line is large enough to appear in gross margin, or when a contract gives the vendor audit rights, which is the point at which being approximately right stops being acceptable.