DDoS Protection - Argos Mesh

Overview

Argos Mesh implements a comprehensive DDoS protection strategy that combines rate limiting, IP blocking, and real-time alerting to defend against distributed denial-of-service attacks. The Sentinel service acts as a security gateway, analyzing traffic patterns and automatically mitigating threats.

The DDoS protection system runs on Java 21 Virtual Threads, enabling it to handle thousands of concurrent connections with minimal resource overhead.

Protection Architecture

The DDoS protection system consists of three integrated components:

TrafficAnalyzer

Monitors request rates using a sliding window algorithm and identifies abusive traffic patterns.

RedisService

Manages a distributed IP blacklist with automatic expiration, shared across all service instances.

SalesListener

Processes events in real-time, coordinating traffic analysis and alert generation.

How DDoS Protection Works

Event Flow

Here’s the complete flow from an incoming request to threat mitigation:

Step 1: Event Generation

When a product is sold, the Shop service publishes a ProductSoldInternalEvent to RabbitMQ:

public record ProductSoldInternalEvent(
    Long productID,
    Integer quantity,
    String ipAddress,
    LocalDateTime timeStamp
) {}

Source: sentinel/src/main/java/com/argos/sentinel/dto/ProductSoldInternalEvent.java

Step 2: Event Reception

The Sentinel service listens on the argos.sales.queue and receives events asynchronously:

@RabbitListener(queues = "argos.sales.queue")
public void processSalesEvents(ProductSoldInternalEvent data) {
    String ip = data.ipAddress();

    if (redisService.isBanned(ip)) {
        return;
    }

    if (analyzer.processAndCheckLimit(ip)) {
        AlertInternalEvent event = new AlertInternalEvent(
            "Suspicious behavior", 
            ip, 
            "CRITICAL", 
            LocalDateTime.now()
        );            
        rabbitTemplate.convertAndSend(
            RabbitMQConfig.ALERT_EXCHANGE,
            "argos.alert.security",
            event
        );
    } else {
        System.out.println("[ Sentinel🛡️ ] Normal traffic of the IP: " + ip);
    }
}

Source: sentinel/src/main/java/com/argos/sentinel/service/SalesListener.java:25-44

Step 3: Blacklist Check

Before analyzing traffic, check if the IP is already banned:

if (redisService.isBanned(ip)) {
    return;  // Silently drop events from banned IPs
}

This prevents banned IPs from consuming resources or generating redundant alerts.

Step 4: Traffic Analysis

The TrafficAnalyzer implements a sliding window rate limiter:

public boolean processAndCheckLimit(String ip) {
    if (redisService.isBanned(ip)) return true;

    String key = RATE_PREFIX + ip;
    
    Long currentCount = redisTemplate.opsForValue().increment(key);

    if (currentCount != null && currentCount == 1) {
        redisTemplate.expire(key, Duration.ofSeconds(WINDOW_SECONDS));
    }

    if (currentCount != null && currentCount > LIMIT) {
        redisService.banIp(ip, 10);
        return true;
    }

    return false;
}

Source: sentinel/src/main/java/com/argos/sentinel/service/TrafficAnalyzer.java:22-39

Parameters:

LIMIT: 50 requests

WINDOW_SECONDS: 10 seconds

Ban Duration: 10 minutes

Step 5: Automatic Ban

When the threshold is exceeded, the IP is banned:

public void banIp(String ipAddress, long durationMinutes) {
    redisTemplate.opsForValue().set(
        BLACKLIST_PREFIX + ipAddress,
        "BANNED",
        Duration.ofMinutes(durationMinutes)
    );
}

Source: sentinel/src/main/java/com/argos/sentinel/service/RedisService.java:19-26

Step 6: Alert Generation

A critical security alert is sent to the alert queue:

AlertInternalEvent event = new AlertInternalEvent(
    "Suspicious behavior",
    ip,
    "CRITICAL",
    LocalDateTime.now()
);

rabbitTemplate.convertAndSend(
    RabbitMQConfig.ALERT_EXCHANGE,
    "argos.alert.security",
    event
);

This alert can trigger notifications, logging, or automated responses in downstream services.

Java 21 Virtual Threads

The Sentinel service leverages Java 21 Virtual Threads for high-concurrency request processing:

spring.threads.virtual.enabled=true

Source: sentinel/src/main/resources/application.properties

Why Virtual Threads?

Massive Concurrency

Handle thousands of concurrent requests without the overhead of traditional threads. Each request gets its own lightweight virtual thread.

Low Memory Footprint

Virtual threads use ~1KB of memory vs ~1MB for platform threads, enabling massive scalability on limited hardware.

Simple Blocking Code

Write straightforward blocking I/O code without callbacks or reactive patterns. Virtual threads make blocking operations efficient.

DDoS Resilience

During an attack, thousands of malicious requests can be processed simultaneously without exhausting thread pools.

Virtual threads are automatically used by Spring Boot 3.2+ when RabbitMQ listeners process messages, making the Sentinel service highly resilient to traffic spikes.

Protection Scenarios

Scenario 1: Scalping Bot Attack

Attack Pattern: A bot attempts to purchase all limited-edition products by making rapid requests.

Bot Sends 100 Requests

A scalping bot sends 100 purchase requests in 3 seconds from IP 203.0.113.42.

Rate Limit Triggered

After request 51, the rate limit is exceeded:

Request 1-50:  ✅ Processed normally
Request 51:    ❌ LIMIT EXCEEDED → IP BANNED
Request 52-100: ❌ Dropped (IP blacklisted)

IP Banned for 10 Minutes

Redis key created:

Key: blacklist:ip:203.0.113.42
Value: BANNED
TTL: 600 seconds

Alert Generated

{
  "type": "Suspicious behavior",
  "sourceIp": "203.0.113.42",
  "severity": "CRITICAL",
  "timeStamp": "2026-03-05T14:32:18"
}

Bot Blocked

All subsequent requests from 203.0.113.42 are silently dropped for 10 minutes.

Scenario 2: Distributed DDoS

Attack Pattern: A botnet of 1,000 infected devices sends traffic from different IPs.

Attack Begins

1,000 bots each send 60 requests in 10 seconds (60,000 total requests).

Individual Rate Limiting

Each bot’s IP is analyzed independently:

Bot 1 (192.168.1.10):  Requests 1-50 ✅ | Request 51+ ❌ BANNED
Bot 2 (192.168.1.11):  Requests 1-50 ✅ | Request 51+ ❌ BANNED
Bot 3 (192.168.1.12):  Requests 1-50 ✅ | Request 51+ ❌ BANNED
...
Bot 1000 (192.168.1.1000): Requests 1-50 ✅ | Request 51+ ❌ BANNED

Attack Mitigated

Processed: 50,000 requests (50 per IP)

Blocked: 10,000 requests (10 per IP)

Reduction: 83% of attack traffic blocked

Virtual Threads Handle Load

Despite 60,000 concurrent events, virtual threads prevent thread pool exhaustion:

Platform Threads: Would need 60,000 threads = 60GB RAM ❌
Virtual Threads:  60,000 virtual threads = 60MB RAM ✅

While the system handles individual IPs well, extremely large botnets (10,000+ IPs) may still cause resource exhaustion. Consider implementing upstream rate limiting at the load balancer level for comprehensive protection.

Scenario 3: Legitimate Traffic Spike

Pattern: Your product goes viral on social media, causing a sudden surge in legitimate traffic.

Surge Begins

10,000 unique users visit your site within 1 minute, each making 5-10 requests.

Rate Limiting Allows Normal Use

Legitimate users stay well under the 50 requests/10 seconds limit:

User 1: 8 requests over 30 seconds   ✅ Not rate limited
User 2: 12 requests over 45 seconds  ✅ Not rate limited
User 3: 35 requests over 60 seconds  ✅ Not rate limited

Virtual Threads Scale Seamlessly

The system processes 100,000 total requests without performance degradation:

Concurrent requests: 10,000
Virtual threads created: 10,000
Memory usage: ~10MB for threads
All requests processed successfully ✅

No False Positives

Because legitimate users don’t exceed 50 requests in 10 seconds, no IPs are banned.

Configuration Recommendations

Development Environment

private static final int LIMIT = 100;           // Higher limit for testing
private static final int WINDOW_SECONDS = 10;
private static final int BAN_MINUTES = 5;       // Shorter ban duration

Production Environment

private static final int LIMIT = 50;            // Strict limit
private static final int WINDOW_SECONDS = 10;
private static final int BAN_MINUTES = 30;      // Longer ban for attackers

High-Security Environment

private static final int LIMIT = 20;            // Very strict
private static final int WINDOW_SECONDS = 10;
private static final int BAN_MINUTES = 60;      // 1-hour ban

For e-commerce platforms during high-traffic events (Black Friday, product launches), consider temporarily raising the limit to prevent false positives.

Monitoring DDoS Protection

Real-Time Metrics

Monitor these key metrics to assess DDoS protection effectiveness:

# Check current banned IPs
redis-cli KEYS "blacklist:ip:*" | wc -l

# Check active rate limit counters
redis-cli KEYS "rate:ip:*" | wc -l

# View recent alerts
redis-cli -h localhost -p 5672 # RabbitMQ Management UI

Alert Queue Analysis

Query the alert queue to see DDoS activity:

# View messages in alert queue
rabbitmqadmin get queue=argos.alert.queue count=10

Example output:

[
  {
    "type": "Suspicious behavior",
    "sourceIp": "203.0.113.42",
    "severity": "CRITICAL",
    "timeStamp": "2026-03-05T14:32:18"
  },
  {
    "type": "Suspicious behavior",
    "sourceIp": "198.51.100.78",
    "severity": "CRITICAL",
    "timeStamp": "2026-03-05T14:32:19"
  }
]

Grafana Dashboard

Create a Grafana dashboard to visualize DDoS metrics:

Banned IPs Over Time

Track the number of banned IPs to detect attack patterns.

Rate Limit Violations

Graph the frequency of rate limit violations to identify attack intensity.

Alert Volume

Monitor the number of security alerts generated per minute.

Request Processing Time

Ensure virtual threads maintain low latency even under attack.

Defense Layers

Argos Mesh implements defense in depth:

Layer 1: Network Edge

CDN/WAF: CloudFlare, AWS Shield

Purpose: Block known malicious IPs before they reach your infrastructure

Layer 2: Load Balancer

Component: NGINX, AWS ALB

Purpose: Connection limiting, SSL termination, basic rate limiting

Layer 3: Application (Sentinel Service)

Component: TrafficAnalyzer + RedisService

Purpose: Intelligent rate limiting, IP blocking, alerting

This is where Argos Mesh DDoS protection operates ✅

Layer 4: Database

Component: Redis connection limits

Purpose: Prevent resource exhaustion at the data layer

Each layer provides protection, but the Sentinel service’s application-layer defense is critical because it understands business logic and can make intelligent decisions about what constitutes abuse.

Best Practices

Deploy Multiple Sentinels

Run multiple Sentinel service instances for high availability. They share Redis state automatically.

Use Redis Cluster

For large-scale deployments, use Redis Cluster to distribute blacklist and counter data.

Monitor Alert Queue

Set up automated monitoring to notify security teams when alert volume spikes.

Implement Whitelisting

Add IP whitelist logic to prevent false positives for internal services and monitoring systems.

Log All Bans

Implement structured logging to track when and why IPs are banned for audit purposes.

Tune for Your Traffic

Adjust rate limits based on your application’s normal traffic patterns. Monitor false positives.

Limitations

IP Rotation: Attackers using proxies or VPNs can rotate IPs to evade bans. Consider implementing additional signals like user-agent fingerprinting or CAPTCHA challenges.

IPv6 Challenges: IPv6 addresses can be easily rotated. Consider rate limiting by /64 subnet instead of individual addresses.

Shared IPs: Users behind corporate NAT or public WiFi share IPs. Aggressive rate limiting may cause false positives. Monitor and adjust accordingly.

Extending Protection

Add CAPTCHA for Suspicious Traffic

Instead of immediately banning, challenge suspicious IPs with CAPTCHA:

if (currentCount > WARNING_THRESHOLD) {
    return Response.status(429)
        .entity(new CaptchaChallenge())
        .build();
}

Implement Progressive Penalties

if (currentCount > LIMIT) {
    int banDuration = calculateBanDuration(ip); // Longer bans for repeat offenders
    redisService.banIp(ip, banDuration);
}

Add Machine Learning

Train a model to detect anomalous patterns:

if (analyzer.processAndCheckLimit(ip) || mlModel.detectAnomaly(data)) {
    // Ban IP
}

Rate Limiting

Detailed explanation of the sliding window algorithm

IP Blocking

How to manually manage the IP blacklist

Architecture

Understand how Sentinel fits into the overall system

Event-Driven Design

Learn about the RabbitMQ event flow

Deployment

Security

​Overview

​Protection Architecture

TrafficAnalyzer

RedisService

SalesListener

​How DDoS Protection Works

​Event Flow

​Java 21 Virtual Threads

​Why Virtual Threads?

Massive Concurrency

Low Memory Footprint

Simple Blocking Code

DDoS Resilience

​Protection Scenarios

​Scenario 1: Scalping Bot Attack

​Scenario 2: Distributed DDoS

​Scenario 3: Legitimate Traffic Spike

​Configuration Recommendations

​Development Environment

​Production Environment

​High-Security Environment

​Monitoring DDoS Protection

​Real-Time Metrics

​Alert Queue Analysis

​Grafana Dashboard

Banned IPs Over Time

Rate Limit Violations

Alert Volume

Request Processing Time

​Defense Layers

​Best Practices

Deploy Multiple Sentinels

Use Redis Cluster

Monitor Alert Queue

Implement Whitelisting

Log All Bans

Tune for Your Traffic

​Limitations

​Extending Protection

​Add CAPTCHA for Suspicious Traffic

​Implement Progressive Penalties

​Add Machine Learning

​Related Resources

Rate Limiting

IP Blocking

Architecture

Event-Driven Design

Build docs developers (and LLMs) love

Overview

Protection Architecture

How DDoS Protection Works

Event Flow

Java 21 Virtual Threads

Why Virtual Threads?

Protection Scenarios

Scenario 1: Scalping Bot Attack

Scenario 2: Distributed DDoS

Scenario 3: Legitimate Traffic Spike

Configuration Recommendations

Development Environment

Production Environment

High-Security Environment

Monitoring DDoS Protection

Real-Time Metrics

Alert Queue Analysis

Grafana Dashboard

Defense Layers

Best Practices

Limitations

Extending Protection

Add CAPTCHA for Suspicious Traffic

Implement Progressive Penalties

Add Machine Learning

Related Resources