# CDNs and Object Storage: Store at the Origin, Serve at the Edge (2026)
> Your app server should not be in the business of serving files. Object storage holds the big stuff at the origin; a CDN caches copies at the edge, near users. Together they're the delivery layer — store the file once, serve it from everywhere.
*Source: https://www.infowok.com/cdn-object-storage/ · Navmeet Kaur · Published July 6, 2026*
---
Picture your application server streaming a 30 MB product video to someone on the other side of the planet. It's tying up a worker, burning bandwidth you pay a premium for, and the user is still watching a spinner because the bytes are crossing an ocean. That's a capable machine doing a job it's terrible at — and it's the default setup more apps ship with than you'd think.
The fix is two components that almost always travel together. **Object storage** is where big files actually belong — the durable origin. A **CDN** caches copies of those files at the edge, close to users. Get both in place and the rule becomes simple: store the file once, serve it from everywhere. This post is part of the **System Design Foundations** series, anchored by the [System Design Building Blocks](/system-design-building-blocks/) overview, and it covers the delivery layer your app server should hand this work off to.
- **Object storage is the origin for big files** — durable, cheap, near-unlimited blob storage (like S3), not a database.
- **A CDN caches at the edge,** serving users from a nearby location so requests rarely reach the origin.
- **Together they're the delivery layer** — take file-serving off your app server entirely, and it gets faster *and* cheaper.
## Object Storage: The Origin for Big Files
Object storage keeps each file as an *object* — the raw bytes plus metadata — addressed by a key and fetched over HTTP. There are no folders in the real sense, just a flat namespace of keys, and no schema or queries. As AWS's [object storage overview](https://aws.amazon.com/what-is/object-storage/) describes it, this design trades a database's querying power for something else entirely: near-unlimited, highly durable, inexpensive capacity for unstructured data. Images, video, backups, logs, user uploads, datasets — anything that's a *file* rather than a *row* lives here. It's the natural counterpart to the database decision in [SQL vs NoSQL](/sql-vs-nosql/): structured records go in a database, big blobs go in object storage.
What object storage is *not* is fast to reach from everywhere. It's one durable home for your files, usually in one region. Which is exactly the gap a CDN fills.
## CDN: Caching at the Edge
A content delivery network is a fleet of servers spread across the globe, each caching copies of your content near users. When someone requests a file, the CDN serves it from the closest edge location instead of your origin. Cloudflare's [CDN overview](https://www.cloudflare.com/learning/cdn/what-is-a-cdn/) sums up the payoff: lower latency for users and dramatically less load on the origin, because most requests never reach it.
The diagram shows the whole idea. A user in Tokyo hits the Tokyo edge; a user in London hits the London edge. The *first* time an edge is asked for a file it doesn't have, it fetches it once from the origin and caches it — a miss. Every request after that is served locally, fast, without troubling the origin at all. A CDN is really [caching](/caching-strategies/) applied to geography: keep a copy close to whoever needs it.
## How They Work Together
Stack them and each does the half it's built for. Object storage is the single durable source of truth for the file; the CDN is the fast, distributed delivery in front of it. You upload once to the origin, put the CDN ahead of it, and users everywhere get an edge-served copy. As Cloudflare's [note on CDN caching](https://www.cloudflare.com/learning/cdn/what-is-caching/) explains, the edge holds the file for a configured time and refreshes from the origin when needed. Your application server, meanwhile, is out of the loop entirely — it never touches the bytes, so it stays free to do logic instead of pushing files.
## The Payoff and the Catch
The payoff is large and immediate: faster loads worldwide, a fraction of the origin traffic, lower bandwidth bills, and file delivery that scales without touching your app. But the catch is the same one that haunts all caching — **staleness**. An edge serves its cached copy until that copy expires, so if you replace a file at the origin, users can keep getting the old one until the cache refreshes. The fixes are the caching fixes: a sensible TTL, explicit *purge/invalidation* when something must update now, or versioned filenames (`logo.v2.png`) so a new file is simply a new URL that was never cached.
The rule of the delivery layer: the origin owns the one true copy; the edge owns speed. Push every large or static file to object storage, put a CDN in front, and keep your app server out of the file-serving business entirely — it's the cheapest performance win most apps are still leaving on the table.
When you update a cached file, don't just overwrite it and hope — either purge the CDN path or change the filename. "Overwrite and wait for the TTL" is how a stale logo lingers for hours after the redesign shipped.
## Object Storage in AI Systems
For AI systems this layer is quietly load-bearing — object storage is where the *biggest* things live.
**It's the origin of an AI system.** Model weights, training datasets, fine-tuning data, and the source documents a [RAG pipeline](/vector-database-for-rag-part-4/) ingests are all files, and files belong in object storage. It's the durable home for everything an AI app is built on — while the *embeddings* derived from those documents go to a vector database, not a blob store, which is the same file-versus-row split as always.
**Loading weights from it is the cold-start tax.** When you scale inference out, each new GPU replica has to pull multi-gigabyte model weights from object storage before it can serve a single token. That transfer is a big part of why autoscaling inference is slow — the exact cold-start cost that shapes [horizontal scaling for GPUs](/horizontal-vs-vertical-scaling/). And on the output side, a CDN earns its keep serving what the model *produces* — generated images, audio, and files — close to the users who requested them.
AI-era rule of thumb: object storage is the origin for model weights, datasets, and RAG source files; a vector database holds the embeddings, not the blobs; and a CDN fronts the generated media your model returns. Budget for the cold-start cost of pulling weights from the origin when a new inference replica boots.
## Quick Recap
- **Object storage = durable origin** for large, unstructured files; cheap, near-unlimited, key-addressed.
- **CDN = edge cache** that serves files from near the user, keeping requests off the origin.
- **Together = the delivery layer** — take file-serving off your app server entirely.
- **The catch is staleness** — use TTLs, purges, or versioned filenames when files change.
- **In AI systems,** object storage holds weights, datasets, and RAG docs; a CDN serves generated media.
## Conclusion
**CDNs and object storage** solve a problem so quietly that plenty of teams never notice they have it: their application server is spending itself serving files it should have handed off. Put the files in object storage where durable, cheap capacity lives, put a CDN in front so every user gets a nearby copy, and keep versioning or purging so the edge never serves yesterday's file. Do that and file delivery stops being your app's problem and becomes infrastructure's — faster for users, cheaper for you, and one less thing that falls over when traffic spikes.
**What finally moved your files off the app server — a brutal bandwidth bill, slow loads overseas, or a box that fell over serving a download?** Tell me what tipped you.
- **[Caching Strategies](/caching-strategies/)** — a CDN is caching applied to geography; the invalidation trap is the same.
- **[SQL vs NoSQL](/sql-vs-nosql/)** — the other half of storage: which data is a row, and which is a blob.
- **[Horizontal vs Vertical Scaling](/horizontal-vs-vertical-scaling/)** — why loading weights from the origin is the cold-start cost of scaling inference out.