One of the questions that naturally comes up when designing a multi-node Onion Service architecture is:
Can decentralization make a service more resilient to DDoS attacks?
The short answer is: it can improve resilience, but it does not make a system DDoS-proof.
That distinction matters.
The single-node problem
Consider a traditional deployment:
Traffic
|
v
+---------+
| Node A |
+---------+
|
Service
If Node A becomes saturated or unavailable, the service may become unavailable.
This creates a straightforward single point of failure.
Adding redundancy changes the architecture:
Traffic
|
+-----------+
| Discovery |
+-----------+
/ | \
/ | \
v v v
Node A Node B Node C
| | |
Service Service Service
Now the system can reason about which nodes are healthy and which services are available.
Health-aware routing
A future Onion infrastructure can maintain node health information:
Node A ✓ healthy
Node B ✓ healthy
Node C ✗ unavailable
The routing layer can then avoid unhealthy nodes.
This doesn't stop an attack.
It provides something different:
controlled degradation.
Instead of treating the entire service as a single unit, the infrastructure can isolate failures and continue operating where possible.
Selective replication
We also don't necessarily want to replicate everything.
Imagine three services:
Service A → replicated
Service B → local-only
Service C → replicated on demand
The infrastructure can place replicas on nodes according to explicit policies.
For example:
Node A
├── Service A
└── Service B
Node B
└── Service A
Node C
└── Service C
If Service A requires higher availability, it has multiple possible locations.
But there is an important limitation
Distributed nodes do not automatically solve DDoS.
If every request must pass through the same bottleneck:
ATTACK
|
v
+-----------+
| Gateway | ← bottleneck
+-----------+
|
+------+------+
| | |
Node Node Node
then adding more nodes behind the gateway may have little effect.
This is why DDoS resilience has to be designed end-to-end.
Multiple layers of resilience
A more complete architecture looks like:
Internet / Tor traffic
|
v
Ingress controls
|
v
Access Gateway
|
Rate limiting
|
Node Discovery
|
+------------+------------+
| | |
Node A Node B Node C
✓ ✓ ✗
| |
Service X Service X
\ /
\ /
Replicated
Service
Each layer has a different responsibility.
Ingress
Controls what reaches the system.
Gateway
Provides authentication, authorization and protocol enforcement.
Discovery
Knows which nodes are available.
Health monitoring
Detects degraded or unavailable nodes.
Replication
Provides multiple service locations where required.
Failover
Moves traffic toward healthy compatible infrastructure.
The real goal: resilience, not immunity
This is an important distinction for any infrastructure project.
We shouldn't claim:
“Our decentralized Onion architecture prevents DDoS.”
A more accurate statement is:
“A multi-node architecture can reduce single points of failure and provide additional mechanisms for controlled degradation and recovery under traffic overload.”
That is a claim we can actually test.
Testing the architecture
The next challenge is therefore not simply implementing more nodes.
It's measuring what happens under stress.
We want to test scenarios such as:
Scenario 1
Node A overloaded
↓
Node B remains available
Scenario 2
Node A unavailable
↓
Health registry detects failure
↓
Node A removed from selection
Scenario 3
Service X overloaded
↓
Replica available on Node B
↓
Service continues
And also the failure case:
All ingress capacity exhausted
↓
Additional nodes cannot help
↓
Architecture reaches its protection boundary
Knowing that boundary is just as important as knowing the system's capabilities.
Our roadmap
For MyZubster / Onion, this naturally leads to a staged architecture:
01 Single-node deployment
↓
02 Security model
↓
03 Authentication & RBAC
↓
04 Node discovery
↓
05 Health registry
↓
06 Selective service replication
↓
07 Failover
↓
08 DDoS resilience & traffic isolation
The principle is simple:
Don't start with a distributed system.
Start with a node that works.
Then make the node observable.
Then add another node.
Then discover nodes.
Then replicate only what needs replication.
Then introduce failover.
And only after that measure resilience under controlled load.
Why Onion Services are interesting here
Onion Services already provide a fundamentally different exposure model from a conventional publicly exposed server.
That makes them an interesting foundation for experimenting with resilient service architectures.
But Tor alone isn't a DDoS mitigation system.
The interesting engineering problem is what we build around the Onion Service:
identity + discovery + health + policy + replication + isolation + recovery.
That's where decentralized infrastructure becomes more than simply running the same application on multiple machines.
MyZubster / Onion is still in the early stages of this roadmap. The multi-node and DDoS-resilience capabilities described here are future architecture and development goals, not claims about functionality already deployed.
We're interested in building and testing these mechanisms incrementally rather than making premature security or availability claims.
If you're working on Tor, distributed systems, DDoS resilience, privacy infrastructure, network security or resilient institutional services, we'd love to hear your perspective.
