Not a refactor. Not a rewrite. A rethink.
And the security improvement was not something I planned. It was a consequence of thinking about the problem correctly.
The Mess That Grew in Silence
Our platform handles media for everything.
User profile pictures. Maintenance job photos. Lease agreements. Inspection reports. Tenancy documents. Contract files. Management agreements. Entry condition reports. Exit condition reports.
Each one slightly different. Some allow multiple files. Some allow only one. Some need a featured image. Some need ordering. Some go to FTP. Some display as a gallery. Some render inline as a PDF. Some generate secure download links.
Over ten years, every developer who touched a new media requirement wrote new code for it. Nobody ever stopped to ask whether there was a single thing underneath all these cases.
By the time I looked properly, the media handling code scattered across the codebase was over 80,000 lines.
But here is the part that troubled me more than the line count.
Every developer had also written their own validation. Their own file type checks. Their own size limits. Some checked properly. Some checked partially. Some forgot entirely. Some checked on the frontend but not the backend. Some checked the file extension but not the actual file signature.
80,000 lines of code meant 80,000 places where a security assumption could be wrong. And in a platform handling legal documents and financial agreements for 50,000 users, that was not acceptable.
The Question That Changed Everything
I did not start by looking at the code. I started by asking a different question.
Not “how do we clean this up” but “what is actually happening in every single one of these cases?”
So I listed every media use case in the system. All of them. Then I wrote down exactly what varied between them.
Here is what I found:
- Allowed file formats (images only, documents, or any file)
- Maximum file size in MB
- Single upload or multiple uploads allowed
- Whether one file can be marked as featured
- Whether files can be manually reordered
- Where files are stored (local, FTP, cloud)
- How files are displayed (gallery, single image, PDF viewer, download link)
- Whether downloads are open or token-secured
That is it. Eight things. Every single media use case in the entire platform was just a different combination of those eight things.
Eighty thousand lines of code. Eight variables.
The Security Insight
Here is what struck me when I wrote that list.
The allowed file formats and the maximum upload size were not just functional requirements. They were security boundaries. And in the old system, those boundaries lived inside individual developer implementations, scattered across dozens of files, written at different times by different people with different levels of care.
That is the worst possible place for a security boundary to live.
When security is in the code, it is only as strong as the most distracted developer on their worst day. Someone is tired, they copy a template, they miss the file type check, they push it, nobody notices, and a vulnerability sits quietly for months.
When security is in the data, it is enforced by one system, consistently, every time, for every case, with no exceptions and no human memory required.
So the architectural decision I made was this: take the security boundary out of the code entirely and put it in the database. Every media type has its allowed formats and its size limit defined in one row. The component reads those values and validates server-side on every upload, automatically, regardless of which developer integrated it or how carefully they were paying attention that day.
A developer cannot accidentally skip validation because there is no validation code to write.
What the System Looks Like
One database table defines every media use case in the platform:
media_types
name varchar
allowed_formats varchar -- e.g. "jpg,png,pdf" or "pdf,docx" or "*"
max_size_mb int -- enforced server-side on every upload
allow_multiple tinyint
allow_featured tinyint
allow_ordering tinyint
storage_target varchar -- local | ftp | s3
display_type varchar -- gallery | single | pdf-viewer | download
secure_download tinyint -- token-based or open
Adding a new media use case anywhere in the platform: insert one row. No code. No deployment. The security rules go in the row along with everything else.
To use media anywhere in the system, this is the entire integration:
<Media type="lease-agreement" :entity-id="lease.id" />
One line. That single tag gives you upload with drag and drop, server-side format validation against the database row, server-side size enforcement against the database row, multiple file support if the type allows it, featured selection if the type allows it, drag-to-reorder if the type allows it, automatic routing to the correct storage target, gallery or PDF viewer or download link based on display type, and token-secured download URLs if the type requires it.
The component does not trust the browser. It reads the allowed formats and size limit from the database and validates the actual file on the server on every upload, regardless of what the client sends.
The Architecture: Before and After
The left side is what every large codebase eventually looks like. Dozens of files, each written by a different developer, each with slightly different validation, each a potential weak point. The right side is one engine reading from one table, enforcing the same rules every time.
The difference is not just aesthetics. On the left, adding a new upload type took a developer roughly two days. Write the upload handler, write the validation, write the display component, test each case, deploy. On the right, adding a new upload type takes five minutes. Open a database panel, insert one row, done. No code, no deployment, no QA cycle, no chance of forgetting the size check.
That is a 96 percent reduction in the time to add a new use case. Not because the new system is faster to code. Because the new system requires no code at all.
What This Taught Me About Architecture
The most expensive code in any large system is not the complex code. Complex code is visible. It gets reviewed, discussed, and questioned.
The most dangerous code is the simple repeated code that nobody looks at twice. The file upload handler. The size check. The format validation. Code that every developer writes slightly differently because it seems too small to think carefully about. In that smallness, across hundreds of instances over years, both maintainability and security erode quietly.
The architectural answer is always the same:
- List every instance of what feels like the same problem
- Write down exactly what varies between them
- Build one thing that takes those variables as configuration
- Replace every instance with that one thing
You do not get cleaner code as a side effect of better security. You get both as a side effect of understanding what the problem actually is.
Most systems become complex gradually, one small exception at a time. Architecture is the discipline of recognising when the exceptions are actually the same problem wearing different clothes.
The media system was the first place I noticed it.
It would not be the last.
Mathavan Jeyadev led the architecture of OurProperty, an Australian property management SaaS serving 50,000 users. He is the creator of DataForge, an open-source Laravel backend framework built on the same architectural thinking described here.
GitHub: github.com/Astra-Techno
Framework: dataforge.cloudship.in
LinkedIn: linkedin.com/in/mathavan-jeyadev-b0920818
Top comments (0)