The slide says single source of truth. The architecture diagram behind it has the DAM in the middle with arrows going out to five systems, and every one of those arrows is labelled sync.
That is not a single source of truth. That is six sources of truth with a preferred one and a nightly job that hopes.
Short answer: you have a single source of truth when consuming systems hold a reference rather than a copy, and derivatives are produced on request rather than stored. Everything else is replication with a favourite. The test is concrete: change the master and count how many systems need to be told. If the answer is more than zero, you have copies, and copies diverge.
The two architectures
Replication. The DAM holds the master. Each consuming system receives a copy, stores it, and serves it. Sync jobs or events keep the copies aligned.
This is how most enterprise estates actually work, and it is not stupid. It is what you get when the consuming systems were built to hold files, which most of them were. It has three permanent costs: storage multiplied by the number of consumers, a divergence window between the master changing and each copy catching up, and a class of bug where one copy silently stops updating and nobody notices for months.
Reference and derivation. The DAM holds the master. Each consuming system holds an address. When a page renders, the asset is fetched from the media platform, transformed to the requirements of that surface, and cached at the edge.
Storage is one master. The divergence window is zero, because there is nothing to diverge. And the failure mode changes from silent staleness to a visible outage, which sounds worse and is much better, because you find out immediately.
The property that makes it work
Reference-only architecture is only viable if the platform can produce any derivative on demand. Otherwise consumers legitimately need their own copies, because their requirements differ.
That is the hinge. When the 400 by 400 thumbnail is a URL parameter rather than a file, the commerce platform does not need a copy. When the 16:9 hero crop is a parameter, the CMS does not need a copy. When the print-resolution CMYK version is a parameter, the print pipeline does not need a copy.
The Cloudinary transformation reference is the full parameter vocabulary for that model, and responsive images covers the case where the required size is not known until the browser knows its own viewport, which no stored-variant approach can handle at all.
Without derivation, “single source of truth” degrades into “the place the copies come from originally”, which is a genuinely weaker claim and should be described as such in your architecture documents.
Where the copies come from
Four legitimate reasons systems keep copies. Each has a specific answer.
Performance. “We cache locally so the page is fast.” Reasonable instinct, wrong solution. Edge caching on immutable derivative URLs gives you the same latency without the storage or the staleness. The mechanics are standard HTTP caching, and the key is a version token in the URL so a replaced master produces a new address rather than requiring a purge.
Availability. “What if the media platform is down.” A real concern that deserves a real answer rather than a copy. Assess the delivery network’s actual availability, decide whether images are on your critical rendering path, and if they are, handle it with graceful degradation and a fallback rather than with a full replica you now have to keep current.
Offline or air-gapped use. Print production, exhibition systems, field distribution. Genuinely legitimate. Export deliberately, mark the export as a point-in-time snapshot, and do not pretend it is synchronised.
The consuming system cannot reference. Some legacy systems can only ingest files. This is the honest case for a scheduled sync, covered as pattern three in integration patterns for an enterprise DAM. Treat it as debt with a name, not as the architecture.
Anything outside those four is a copy that exists because nobody asked whether it needed to.
How do you test whether you have it?
Five questions. Run them against your current estate and the answer will be uncomfortable and useful.
- Change a master. How many systems need to be told? Zero is reference architecture. Any other number is replication.
- Delete a master. What happens to the derivatives? They should stop resolving immediately. If copies survive deletion, you cannot execute a takedown, a rights expiry, or a privacy deletion request, and that is a compliance problem rather than an architectural preference.
- Count distinct masters, then count total stored files. The ratio is your replication factor. It should be close to one.
- Ask for a new aspect ratio for a new channel. If the answer is a batch job, you are storing variants. If it is a string change, you are deriving them.
- Who can edit the description field? If more than one system allows editing, you have two sources of truth for that field regardless of what the diagram says. The ownership discipline for this is in who owns which record.
What single source of truth does not mean
Three misreadings that cause real design errors.
It does not mean one system holds everything. Product data belongs in the PIM and page structure belongs in the CMS. Single source of truth is per field, not per system. Every field has exactly one authoritative home, and different fields have different homes.
It does not mean no caching. Caches are copies with a defined lifetime and an eviction policy, which is what makes them different from replicas. A cache that never expires is a replica wearing a disguise.
It does not mean one physical store. Backups, disaster recovery replicas and archive tiers are all copies and all correct. The distinction is that none of them is independently editable. A copy that cannot be written to is not a second source of truth, it is durability. Version management and backup is the sanctioned form of this.
Version identity is the part people get wrong
If derivative URLs are immutable and cacheable, replacing a master has to produce new URLs. Otherwise you are choosing between short cache lifetimes, which costs performance, and stale images, which costs correctness.
The standard solution is a version token in the address, so .../v1718294/asset.jpg becomes .../v1719901/asset.jpg when the master changes. Old URLs keep resolving to the old bytes, which is usually what you want for anything already printed or emailed, and new references pick up the new version automatically.
Two consequences worth designing for deliberately:
- Consuming systems must store the reference without the version, and resolve the current version at render time. Otherwise every consumer holds a pinned old version and you are back to replication, just with URLs instead of files.
- You need an explicit policy on whether replacing an asset should update existing placements. Sometimes yes, a corrected logo. Sometimes no, an image in a published legal document. That is a business rule and it belongs in the asset lifecycle, not in whatever the platform happens to do by default.
The compliance argument
The strongest case for this architecture is not efficiency, it is that certain obligations are only executable under it.
When a licence expires, the asset has to stop being served. When someone exercises a deletion right over a photograph in which they are identifiable, every instance has to go. When a claim is disputed, an image has to come down within hours across every surface.
Under reference architecture those are one operation on one object. Under replication they are a search, across systems you may not control, with no guarantee you found everything. The rights model that depends on this is in rights and expiry as first-class asset data, the access half is in access control, SSO and audit trails, and the API properties that make it possible at all are in headless DAM.
If you are still building the foundational case, what enterprise DAM actually is covers the ground underneath this one.