Most software platforms make the same assumption when it comes to security: if you want control, visibility, and governance, you need to centralize the data.
When our team started working on a specific project, we weren't convinced that assumption was true.
The goal seemed straightforward at first. We needed to build a platform capable of delivering enterprise-grade security for sensitive files and digital assets.
But the deeper we went into the problem, the more I realized security wasn't the real challenge.
The real challenge was balancing four competing objectives at the same time:
-
Strong security
-
Customer ownership of data
-
Long-term scalability
-
Infrastructure efficiency
Most architectures do a good job solving one or two of these requirements.
Solving all four simultaneously is where things become difficult.
The tradeoff most platforms accept
When organizations need secure file management, the industry default is usually the same.
Centralize everything.
Store the files in platform-managed infrastructure.
Process them through centralized systems.
Apply permissions, governance, and auditing from a single control point.
It's a model that works well in many situations.
But it also introduces tradeoffs.
As usage grows, storage requirements increase. Processing demands increase. Infrastructure costs rise. More systems need to be maintained. More data moves through centralized environments.
And from a security perspective, concentrating large amounts of sensitive information in a single location naturally creates a larger attack surface.
The more our team analyzed this model, the more it felt like we were solving one problem while creating several others.
That's when we started questioning the assumption behind it.
Did security really require centralization?
Or was centralization simply the way most platforms had chosen to implement security?
The complexity behind the decision
What made this challenge interesting wasn't the security requirements themselves.
It was the interaction between all the requirements.
If I optimized purely for security → centralization was an easy answer.
If I optimized purely for ownership → I could leave everything inside the customer's environment.
If I optimized purely for cost → I would make completely different architectural decisions.
The challenge was finding an approach that balanced all of them.
Every architectural decision affected something else.
More centralization improved visibility but increased infrastructure dependency.
More distributed processing reduced infrastructure requirements but introduced new design considerations around governance and access control.
There wasn't an obvious answer.
The architecture had to solve multiple problems at once.
The insight that changed the design
The breakthrough came when I realized we were asking the wrong question.
Up to that point, we had been focused on where files should live.
The more important question was who should govern access to them.
That distinction changed everything.
We realized the platform didn't need to be responsible for storing and processing every file in order to provide security.
Its real responsibility was determining:
-
Who can access a resource
-
Under what conditions access is granted
-
What permissions are available
-
Which policies apply
-
How activity is audited and monitored
Once we separated governance from file processing, the architecture became much clearer.
The platform could focus on identity, authorization, policy enforcement, and auditability while file processing remained as close as possible to the data source.
Instead of becoming the center of every operation, the platform became the trusted control layer.
Why we chose a distributed architecture
That insight led our team toward a distributed processing model.
Rather than routing large encrypted files through centralized infrastructure, processing occurs within the client environment whenever possible.
From an engineering perspective, this solved several problems simultaneously.
It reduced unnecessary data movement
It reduced dependency on centralized storage and compute resources
It prevented the platform from becoming a bottleneck as usage increased
And it allowed organizations to maintain ownership of their own files and storage environments
And it allowed organizations to maintain ownership of their own files and storage environments.
Most importantly, it allowed us to maintain strong governance and security controls without requiring customers to surrender control of their data.
The architecture scales because of how it is designed, not because additional infrastructure is continuously added.
The outcome
One of the most rewarding aspects of the project was seeing how architectural choices translated directly into business outcomes.
Because the platform does not act as a centralized processing hub, infrastructure growth is no longer directly tied to usage growth.
For N recipients, blob write cost reduction of local encryption/decryption: 100%
Recipients |
Old blob writes |
New blob writes (local) |
Savings |
1 (self / watch folder) |
1 |
0 |
100% |
3 |
3 |
0 |
100% |
10 |
10 |
0 |
100% |
50 |
50 |
0 |
100% |
Egress bandwidth → near-100% reduction on decrypt
We migrated from an architecture that transferred the whole file plus a 33% of its size (133%) to a schema that transfers a few KB depending on policies and recipients, it’s not related to file size.
Because file processing remains close to the source, unnecessary storage, bandwidth, and compute costs are reduced.
Server CPU → near-100% reduction for large files
On the first implementation, the server executed the processes on the entire file for encryption and again for decryption, streamed in 1 MB chunks. Now for a 100 MB file with 3 recipients, that was 400 MB of server-side processing vs ~2 KB currently. That's effectively a ~99.999% reduction in compute per decrypt event.
Because sensitive assets spend less time inside centralized systems, the attack surface becomes smaller.
And because governance remains centralized, organizations still benefit from the visibility, auditability, and compliance controls they expect from enterprise-grade platforms.
The result is a system that is secure, scalable, and operationally efficient while allowing customers to retain ownership of their data.
Overall estimate for a typical use case
Concrete example → 100 MB file, 3 recipients, opened 20 times
|
|
Old (cloud) |
New local IKD |
Server AES processed |
(3+1) × 100 MB = 400 MB |
~1 KB |
Blob storage used |
300 MB |
0 MB |
Total egress |
20 × ~133 MB ≈ 2.66 GB |
20 × 50 B ≈ 1 KB |
Total ingress |
~100 MB |
~few KB |
API calls |
5 |
7 |
What this project reinforced for me
One lesson I've learned throughout my career is that many scalability challenges are actually architecture challenges.
When systems begin to grow, the natural instinct is often to add more infrastructure.
→ More storage.
→ More processing.
→ More services.
Sometimes that's necessary.
But often the better solution is to revisit the assumptions behind the design itself.
In this project, the assumption was that security required centralization.
Once our team challenged that assumption, a different solution emerged.
By separating governance from file processing, we were able to build a platform that delivers strong security, supports enterprise growth, and minimizes infrastructure dependency.
For us, this project reinforced what good architecture is really about.
Not adding complexity.
Designing systems that eliminate it.