WebShield currently provides basic protection suitable for small to medium-sized applications, where traffic spikes are not extremely frequent or unpredictable.

These types of applications typically don’t have a large number of concurrent users and often operate within a traffic range of 0 to 50 active users. However, it’s important to account for the fact that static files (like CSS, JS, and images) are also requested. On initial page load, a single user might generate up to 200 or more HTTP requests. All further requests should receive some fetch() data (up to 10 requests), but the posts or goods preview probably should have images (with average pagination per 20 items it should be 20 images).

Let’s estimate:

• If 10 users are browsing your site concurrently, total requests might reach 2000 at first loading and 300 for each next
• If there are 50 concurrent users, it might go up to 10000 requests at first loading and 1500 for each next
• The average RPS over the last 10 seconds should be (1(sec) * 50(users) * 200(requests) + 9(sec) * 50(users) * 30(requests)) / 10(sec) = 2350 RPS

Requests alone are not the only important metric.

Static file requests are usually handled directly by Tempesta FW without reaching the backend. However, dynamic page generation or API calls (e.g., fetch() requests) hit the backend and consume time.

If your backend is slow and receives 1000 requests, you’ll likely observe a noticeable increase in accumulated response time — which is a key indicator of server load.

A spike in errors (like 5xx responses) is a strong signal of a problem. If you’re seeing dozens of such responses, it likely means something is going wrong and needs attention.

Based on a typical blog or online shop scenario, the following configuration is a reasonable starting point:

DETECTORS=["tft_rps","tft_time","tft_errors"]
BLOCKING_TYPES=["tft"]
BLOCKING_WINDOW_DURATION_SEC=10

These detectors and time limits balance between responsiveness and protection, ensuring that legitimate traffic is allowed while abnormal spikes can be mitigated early.

Let’s assume you’re running a cryptocurrency exchanger or a small online game. With good marketing, you’re likely to see consistent user traffic. Depending on the complexity of the application, there may be dozens of AJAX requests per user — or even persistent WebSocket connections delivering real-time data, such as coin prices or player actions.

This type of behavior significantly increases the total number of requests, many of which cannot be cached by Tempesta FW, leading to heavier load on your backend services.

The mitigation strategy is similar to that of a blog or e-commerce site.

Additionally, for such dynamic applications, it’s highly recommended to use training mode with either historical or real value. In this mode, the WebShield will analyze real user traffic and determine the most suitable threshold values for filtering potential attacks without affecting normal operation. Probably, its good to define persistant users of your REST-API from mobile clients or commercial users.

To enable real-time training, update your configuration like this:

TRAINING_MODE="real"
TRAINING_MODE_DURATION_MIN=10
PERSISTENT_USERS_ALLOW=True
PERSISTENT_USERS_WINDOW_OFFSET_MIN=10
PERSISTENT_USERS_WINDOW_DURATION_MIN=10
DETECTORS=["tft_rps","tft_time","tft_errors"]
BLOCKING_TYPES=["tft"]
BLOCKING_WINDOW_DURATION_SEC=10

This setup allows the script to observe traffic for 10 minutes, calculate real averages, and apply scaled thresholds based on live behavior — which is ideal for dynamic, traffic-intensive apps.

In large-scale applications, traffic patterns can vary significantly depending on many factors, such as:

• Marketing campaigns
• Time of day
• Holidays
• Black Friday or other sales events
• Political or social events
• Regional incidents or frustration
• And many others

There are plenty of real-world scenarios where traffic might resemble a DDoS attack — but in fact, it’s legitimate. To avoid blocking real users in such cases, it’s important to make thresholds dynamically adaptive.

Moreover, if traffic surges are predictable (e.g. due to a scheduled event or planned marketing campaign), it’s possible to pre-train or pre-configure the system with expected behavior — reducing the risk of false positives.

In future versions, integrating traffic forecasting or external signal sources could help the WebShield make smarter decisions.