Your Backend Shouldn’t Store Your Files
When I first started building backend applications, storing a file felt ridiculously simple.
A user uploads an image.
The server receives it.
I save it somewhere on the server and store the file path in the database.
Done.
Except it isn’t.
Imagine your application starts getting thousands of users uploading images, PDFs, videos, or other files.
Suddenly, your backend server is doing two very different jobs:
Running your application and storing your files.
And that creates problems.
What happens when you scale?
Suppose your application is running on one server.
You now add a second server because traffic has increased.
But the files uploaded to Server 1 aren’t automatically available on Server 2.
Now you have to deal with shared storage, synchronization, replication and a bunch of problems that your application shouldn’t really have to care about.
And that’s just scaling.
There is also durability.
If your server crashes, gets replaced, or you redeploy it, you don’t want your users’ files disappearing with it.
I saw this problem while building HoardSpace
HoardSpace deals with a lot of images.
Every billboard listed on the platform can have multiple images associated with it.
Imagine storing all of those images directly on our backend servers.
As the number of billboards grows, the amount of storage grows with it.
Now imagine we have multiple backend servers.
A request might reach Server A, while the image someone needs happens to exist only on Server B.
That’s not a problem we want our application servers to solve.
So instead of treating our backend server as a giant hard drive, we separate the two responsibilities.
The backend manages the billboard data and business logic.
Get Ayantik Sarkar’s stories in your inbox
Join Medium for free to get updates from this writer.
Object storage manages the actual images.
Conceptually:
HoardSpace → Backend → Object Storage
The database stores information such as the billboard ID, location and the URL of its images.
The actual image files live somewhere designed specifically to store files.
Now we can add or replace backend servers without having to move thousands of images around.
But there is another problem
HoardSpace users can be anywhere.
If someone in Delhi opens a billboard listing and needs to download an image stored far away, we don’t want every request travelling all the way to the storage server.
This is where a CDN becomes useful.
The architecture can become:
User → CDN → Object Storage
Frequently requested images can be served from an edge location closer to the user.
The backend doesn’t need to sit in the middle of every image download.
That’s important because the backend should spend its resources doing backend work, not repeatedly pushing the same 2 MB billboard image to hundreds of users.
The bigger lesson
The interesting part isn’t really S3, R2 or the CDN.
It’s the idea of separating responsibilities.
Your backend should run your application.
Your database should store structured data.
Object storage should store files.
And the CDN should help deliver those files efficiently.
While building HoardSpace, this distinction became much clearer to me.
At small scale, storing files directly on your server feels convenient.
At larger scale, that convenience becomes technical debt.
Good backend architecture isn’t always about adding more complicated technology.
Sometimes it’s simply about putting each responsibility in the right place.
Instead of asking:
“Where can I store this file?”
I think a better question is:
“Which system should be responsible for this?”
