Object Storage Explained

Table of Contents +

Think about an app like Instagram or YouTube for a second:

Millions of people upload photos and videos every single day.
Each one of those files has to be saved somewhere safe, and stay reachable forever.
That’s a mountain of files. So where do apps actually keep all of it?

The answer for most of them is object storage. So let’s walk through what that is, why it exists, and when you’d reach for it. By the end you’ll be able to explain it cleanly in an interview.

🎯 The Problem

Okay so first, why not just use a normal file system like the one on your laptop? Here’s where that falls apart at scale:

A regular file system keeps everything in folders inside folders, like a big tree. That’s fine for a few thousand files.
But once you’re talking millions or billions of files, that tree gets slow and painful to manage.
These files are also unstructured data. Unstructured data just means stuff that doesn’t fit neat rows and columns, like photos, videos, PDFs, and audio.
And you usually can’t grow one disk forever. Sooner or later you run out of space and have to juggle more machines yourself.

So the pain is real: regular file systems just weren’t built to hold a huge, ever-growing pile of unstructured files. We need something made for exactly that job.

📦 What is Object Storage

Object storage is a way of saving data where each file is kept as a self-contained object. Let’s break down what that means:

An object is not just the raw file. It’s the file’s data bundled together with some extra info and a label to find it by.
Each object has three parts: the data (the actual bytes of your photo or video), the metadata (info about the file), and a unique id (its address, so you can fetch it later).
Metadata is just data about the data. Things like when it was uploaded, its file type, its size, or any custom tags you attach, like owner: alex.
The unique id is often called a key. You hand the system that key and it hands you back the object.

And here’s the part that surprises people:

All the objects live in one big flat namespace. Flat namespace means there are no real folders or nested trees, just one giant pool of objects.
You don’t browse a folder path to find your file. You ask for it by its key, more like looking something up by name in a phone book.
You reach all of this over the web, using HTTP requests. So an object store behaves like a web service you send simple requests to, not a disk you plug in.

HTTP, in one line

HTTP is the same language your browser uses to load web pages. With object storage, your app sends an HTTP request like “save this object” or “give me that object,” and the storage service answers back.

🧩 How It’s Organized

If there are no folders, how do you keep things tidy? You use buckets. Here’s the layout:

Objects are grouped into buckets (some clouds call them containers). A bucket is just a named space that holds your objects.
Inside a bucket it’s still flat. There’s no real folder tree, even if a key looks like a path.
A key like photos/2026/alex.jpg looks like folders, but the slashes are just part of the name. The system reads it as one long label, not a folder structure.
To get an object back, you ask for it by its key, or you hit its URL directly. So every object can have its own web address.

Here’s the whole idea in one picture. Your app talks to the object store over an API, and what it gets back is an object made of data, metadata, and an id:

So the mental model is simple: a bucket full of objects, and you grab any object by its key over HTTP.

⚡ Why It’s Great

Object storage got popular for good reasons. Here’s what makes it such a strong fit for big apps:

It scales almost without limit. You just keep adding objects, and the cloud handles spreading them across many machines in the background. You never think about running out of one disk.
It’s cheap, especially for data you don’t touch constantly. Storing a terabyte of old photos costs very little compared to fancy fast storage.
It’s durable. Durable means your data survives even if hardware fails. The service quietly keeps several copies of each object on different machines, which is called replication. So if one machine dies, your file is still safe.
It’s reachable from anywhere over the web, since every object can have a URL. That makes it perfect for serving files straight to browsers and apps.

So what is it actually good for? Things like:

User uploads, like profile pictures and video clips.
Static website assets, like images, CSS, and JavaScript files.
Backups and archives you want to keep safe but rarely open.
Logs and other data your app produces in huge volumes over time.

⚠️ What It’s Not Good For

Object storage is great, but it’s not the answer for everything. It has real trade-offs you have to respect:

You can’t edit part of an object in place. To change one line in a file, you usually have to upload the whole object again. So it’s bad for files that change a tiny bit, constantly.
It has higher latency than a local disk. Latency is the wait time for each request. Going over the network is slower than reading from a disk sitting right next to your processor.
It’s not built for running a database on top of it. Databases need fast, frequent, tiny reads and writes, and object storage just isn’t tuned for that.

So here’s a quick cheat sheet for when to use it and when to look elsewhere:

Great fit for object storage	Not a fit (use something else)
Photos, videos, and audio uploads	A live database with constant small writes
Backups and long-term archives	Files you edit a little bit, very often
Static site assets served to browsers	Low-latency random reads and writes
Logs and big write-once data	An operating system’s boot drive

🌍 Real Examples

You’ve almost certainly used object storage already without knowing it. Here are the big names and what people store in them:

Amazon S3 is the most famous one. S3 stands for Simple Storage Service, and it pretty much defined how object storage works. Huge parts of the internet keep their files in S3.
Google Cloud Storage is Google’s version, and Azure Blob Storage is Microsoft’s. (Blob just means a big chunk of unstructured data, so blob storage is the same idea under a different name.)
A photo app saves every user upload as an object in a bucket, then serves it back by URL.
A website hosts its images, stylesheets, and scripts as objects, often with a CDN in front to make them load fast worldwide.
A company dumps nightly database backups into a bucket, where they sit cheaply until they’re ever needed.

Object storage and CDNs go together

Object storage holds the original files. A CDN keeps copies of them close to users around the world so they load quickly. You’ll see this pairing constantly: files live in a bucket, and a CDN serves them fast.

⚠️ Common Mistakes and Misconceptions

A few ideas trip people up early on. Let’s clear them out:

“Object storage is just a file system.” Not really. It looks similar, but there are no real folders, you fetch by key over HTTP, and you can’t edit a file in place. It behaves like a web service, not a disk.
“It’s a database.” No. You can attach metadata and tags, but it’s not built to query and update tiny records fast. Reach for an actual database when you need that.
“I’ll use it for low-latency random writes.” Bad idea. Object storage is tuned for whole objects written once and read many times, not for constant little changes. For that you want block storage or a database.
“Those slashes in the key are folders.” They’re not. A key like photos/alex.jpg is one flat label. The slashes just help you organize names, but the system sees no folder tree.

🛠️ Design Challenge

Try this one on your own to test yourself.

Imagine Alex is building a video-sharing app. Users upload clips, and viewers watch them later. Think through the storage:

Where do the raw video files go, and why object storage over a regular file system?
What metadata would you attach to each video object, like owner, upload time, or length?
How would you serve those videos quickly to viewers around the world?
What would you keep in a separate database instead of in object storage, like user accounts and comments?

Sketch out your answer. This is exactly the kind of storage reasoning that comes up in system design interviews.

🧩 What You’ve Learned

You can now explain object storage clearly. Here’s what you’ve picked up.

✅ Object storage saves each file as an object: the data, its metadata, and a unique id.
✅ Objects live in buckets in a flat namespace, with no real folder tree, and you fetch them by key over HTTP.
✅ It scales almost infinitely, stays cheap, and is durable thanks to replication.
✅ It’s perfect for unstructured data like images, video, backups, and logs.
✅ It’s a poor fit for in-place edits, low-latency work, and running databases.
✅ Real examples include Amazon S3, Google Cloud Storage, and Azure Blob Storage.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

🚀 What’s Next?

Object storage is one piece of the storage picture. Next, look at how it compares to the other options and how files get served fast.

Block Storage Explained covers the raw-disk storage that databases and operating systems run on.
CDN Explained shows how copies of your files get served quickly to users all over the world.

Once you’ve got those, you’ll understand how modern apps store and deliver data at scale.

Previous Thread Pools Next Block Storage Explained

Share & Connect

Share on LinkedIn