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 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 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: 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 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 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 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 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. 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 — a CDN is caching applied to geography; the invalidation trap is the same.
- SQL vs NoSQL — the other half of storage: which data is a row, and which is a blob.
- Horizontal vs Vertical Scaling — why loading weights from the origin is the cold-start cost of scaling inference out.
