DDoS Protection During Flash Sales: Distinguishing Real Traffic from Attacks

1. Why is Flash Sale season prime bait for DDoS?

Flash Sale represents the peak of revenue generation, but it is also when systems are most vulnerable. Hackers exploit the natural traffic pressure itself to conceal their attacks, using the chaos of peak hours as a perfect cover for infiltration.

During the sale window, requests flood the system in exactly the pattern of real users: browsing products, adding to cart, and checking out simultaneously. The system operates at its capacity limit and the technical team is intensely monitoring every metric. This creates ideal conditions for attackers to launch HTTP Flood attacks at the application layer, simulating normal browsing behavior so convincingly that traditional monitoring systems cannot tell the difference. Simultaneously, volumetric attacks at Layer 3/4 target bandwidth, creating network congestion right before the sale opens so the system enters the battle already weakened.

The most dangerous aspect is that hackers do not need a large-scale attack. They only need to push the system past its load threshold, which is already near capacity during a Flash Sale, to cause a crash. The cost of attack is low, while the damage to the business is extremely high, because every minute of downtime equates to tens to hundreds of millions of VND in lost revenue.

2. Distinguishing real traffic from DDoS during Flash Sales

Differentiating legitimate traffic from DDoS during a Flash Sale is harder than usual because both produce spikes simultaneously. The table below summarizes five core criteria for rapid assessment:

2.1. Characteristics of real traffic during Flash Sales

Legitimate traffic during a Flash Sale carries consistent characteristics that can be used as a comparison baseline. Real users typically access from multiple geographic regions, using browsers with a diverse range of User-Agent strings across versions and devices. Their navigation journey has depth: they browse multiple product pages, read descriptions, add items to the cart, and then complete checkout. Average session duration usually lasts several minutes, not a few seconds.

More importantly, real traffic during Flash Sales is predictable: the spike starts exactly at the sale launch, peaks within the first 10 to 15 minutes, then naturally tapers as stock runs out. This is the normal signal the technical team should establish as a reference benchmark. Setting up load balancing with the correct configuration before the sale helps clearly identify this baseline.

2.2. Identifying signs of Volumetric DDoS (Layer 3/4)

Volumetric attacks target the network infrastructure layer, aiming to saturate bandwidth before requests even reach the application server. The telltale sign is an abnormally sudden spike in network traffic that does not correlate with any sale event. Packet sizes are often unusually uniform because they are auto-generated. The connection error rate increases at the network layer even while the application server has not yet received traffic. This type of attack typically occurs before the sale window to pre-weaken the infrastructure, or is combined simultaneously to divide the attention of the technical team.

2.3. Identifying signs of Layer 7 DDoS and bot attacks

Layer 7 DDoS is more dangerous because it simulates legitimate HTTP behavior. Botnets send requests to high-load endpoints such as the checkout page, search API, or hot product pages. Identifying signs include: User-Agents that are identical in bulk or completely absent, no valid session cookies, requests arriving at the same URL at a fixed periodic interval, absence of natural navigation behavior such as referrers, scroll events, or content read time, and an order completion rate of zero despite very high request volume.

The most serious mistake is deciding to block IPs based solely on traffic volume without analyzing behavior. During a Flash Sale, high volume is normal. Blocking based on absolute thresholds will inadvertently block real customers. The second mistake is ignoring sophisticated Layer 7 bots because the system has no behavioral detection rules, only volume detection rules. The latest generation of Layer 7 attack bots can simulate browser fingerprints, rendering simple filtering solutions completely ineffective.

3. Common mistakes when assessing traffic during Flash Sales

During a Flash Sale, time pressure and the volume of simultaneous alerts make it easy for the technical team to make misjudgments. These mistakes do not just miss attacks; they can also cause direct damage by blocking real customers right during the peak revenue window.

3.1. Blocking IPs based on traffic volume alone

This is the most common and also the most serious mistake. When a range of IPs generates a large volume of requests, the natural reflex is to block immediately. However, during a Flash Sale, high volume is the normal state. A group of users sharing the same ISP, the same geographic region, or all accessing through a corporate NAT gateway can easily generate large traffic from a narrow IP range without any sign of an attack.

• Blocking based on absolute thresholds without cross-referencing historical baselines will inadvertently block real customers.
• An appropriate threshold for a normal day may be 5 to 10 times lower than a reasonable threshold during a Flash Sale.
• The consequence is direct lost revenue, and customers who are mistakenly blocked typically do not return.

3.2. Overlooking Layer 7 bot attacks due to absence of behavioral detection rules

Many systems only configure rules based on request volume or per-IP frequency, entirely lacking a layer of navigation behavior analysis. The latest generation of Layer 7 attack bots can simulate browser fingerprints, carry valid User-Agents, and even complete a few steps in the purchase journey to bypass simple filters.

• Sophisticated bots can simulate clicks, scrolls, and valid sessions, rendering volume-based rules completely ineffective.
• Without monitoring session depth, order completion rate, and referrer patterns, Layer 7 bots can operate throughout an entire Flash Sale undetected.
• The consequence is servers being drained of resources at heavy endpoints like checkout and payment APIs without any clear alert triggering.

3.3. Failing to establish baselines from previous Flash Sales

Without a baseline, every alert threshold is guesswork. The technical team cannot tell whether 300% of normal traffic is normal or abnormal on a sale day, leading to two extremes: either overly sensitive alerts generating constant noise, or thresholds set too high so that real attacks go undetected in time.

• Baselines must be built from actual data from at least 2 to 3 previous Flash Sales, including request rates per endpoint, error rates, session depth, and conversion rates by time slot.
• Alert thresholds must be reviewed before each major sale season; a single fixed number should never be applied across the board.

3.4. Failing to segment thresholds by endpoint type

Applying the same rate limit threshold across the entire system is an imprecise approach. A product listing page naturally handles far more requests than a checkout or payment API page. Setting the same threshold for both groups leads to one of two equally bad outcomes: either checkout is left exposed, or the product page gets mistakenly blocked during peak traffic.

• Critical endpoints such as /checkout, /payment, and /order require much stricter protection thresholds than product browse pages.
• Configuring rate limits per endpoint is a minimum requirement before each Flash Sale season.

3.5. Concentrating all real-time judgments and decisions on a single person during peak hours

When all technical decisions fall on a single individual during peak hours, risk increases significantly. Psychological pressure, sleep deprivation ahead of sale day, and the volume of simultaneous information are the worst possible conditions for making accurate judgments.

• Response procedures, action thresholds, and decision-making authority must be clearly defined and tested before sale day, not left for discussion during peak hours.
• Separating roles between the metrics monitor, the analyst, and the decision-maker helps significantly reduce response time and minimizes the risk of pressure-induced errors.

4. Key technical metrics to monitor in real time during Flash Sales

Accurately identifying traffic patterns requires continuous monitoring of four core metrics throughout the Flash Sale. These are the foundation for precise judgment and timely action:

• Request rate per endpoint: monitor each critical endpoint separately, such as product pages, shopping cart, checkout, and payment API. Detecting which endpoint is receiving abnormal request volumes compared to the baseline from the same time window in previous Flash Sales is the first signal that warrants investigation.
• Error rate (4xx/5xx ratio): a sudden spike signals the server is being overloaded or is under an application-layer attack. An error rate exceeding 5% for more than 2 consecutive minutes is a threshold that warrants immediate intervention.
• Session depth: an abnormally low average number of pages per session, below 2 pages per session while traffic is very high, is a clear indicator of bots with no natural browsing behavior.
• Conversion rate: a sharp drop in conversion rate versus baseline while traffic does not decrease indicates that the majority of traffic is not genuine buyers. This is a concerning signal, particularly given research from count.co showing that pages loading slower than 4 seconds suffer up to 50% lower conversion rates compared to fast-loading pages, and DDoS makes systems far slower than that threshold.
• Ratio of new IPs versus returning IPs: if the proportion of entirely new IPs exceeds 80 to 90% of total traffic within a short window and no marketing campaign explains it, this is a signal that warrants immediate investigation. Large volumes of new IPs appearing simultaneously are typically a sign of a botnet rotating addresses to bypass IP-based blocking rules.
• Geographic distribution of traffic: cross-reference the actual geographic distribution against the marketing reach of the campaign. Traffic suddenly flowing in from regions outside the target customer base, particularly from multiple countries simultaneously, is a clear sign of a distributed botnet that should be contained immediately rather than waiting for additional signals.
• Response time per endpoint: monitor response times in detail per critical endpoint rather than only looking at the overall average. When a specific endpoint such as /search or /product-detail shows a sudden spike in response time while other endpoints remain normal, this signals that the endpoint is being specifically targeted and requires a scoped response rather than a system-wide intervention.

All of these alert thresholds must be configured based on real data from previous Flash Sales, never generic values.

5. When to activate emergency response mode?

Identifying the right moment to activate a response is the most critical skill during Flash Sale peak hours. Acting too early causes unnecessary service disruption; acting too late allows the attack to escalate out of control.

The technical team should activate emergency response when at least two of the following signals are present:

• Error rate exceeds 5% for more than 2 consecutive minutes with no internal technical explanation.
• Request rate to a specific endpoint increases more than 300% above the baseline from the same time window in previous Flash Sales.
• Multiple abnormal metrics appear simultaneously within the same short time window, for example error rate rising while session depth falls, rather than a single isolated metric fluctuating.
• The system has triggered auto-scaling but the overload condition does not improve, indicating the issue is not from resource shortage but from abnormal traffic.
• A completely new range of IPs suddenly accounts for a large share of traffic with no connection to any active marketing channel.

Critically, all of these activation thresholds must be established, aligned across the team, and tested before sale day. During peak hours, there is no time for discussion or seeking approval. Clearly assigning who has authority to activate the response, separate from the person monitoring metrics, significantly reduces response time when an incident occurs. Zero trust is the foundational principle to apply: every abnormal traffic spike must be verified before being considered legitimate.

6. The cost of a DDoS attack during Flash Sale season

A Flash Sale lasts only a few hours. Every minute the system is unresponsive is time that cannot be recovered, and the damage extends far beyond that day's revenue.

6.1. Direct revenue loss

When the system slows down or crashes during a Flash Sale, customers do not wait. Carts are abandoned, orders go uncompleted, and buyers switch to competitors immediately because similar promotions are always running simultaneously across multiple platforms. For a large e-commerce platform, just 30 minutes of downtime during the golden window can wipe out the entire revenue plan for a whole campaign.

6.2. Operational and technical damage

Manual DDoS response during peak hours puts the technical team in an extremely risky situation. Time pressure leads to wrong decisions, such as mistakenly blocking valid IP ranges or disabling security features to free up resources, creating new vulnerabilities in the middle of an active attack. The cost of emergency incident response and post-attack system recovery typically far exceeds the cost of preventive measures.

6.3. Brand damage and loss of customer trust

A poor purchase experience during a Flash Sale leaves a lasting impression. Customers share immediately on social media, negative reviews spike at the most sensitive moment. Users who have experienced a website crash during a sale typically do not return for subsequent sale events, directly impacting long-term retention rates.

6.4. Double attack risk: DDoS combined with security breach

Professional hackers often use DDoS as a smokescreen while simultaneously exploiting security vulnerabilities. While the technical team is focused on responding to DDoS, SQL injection or XSS attacks targeting customer data and payment information can go undetected. This scenario is particularly dangerous because the consequences of a data breach extend for months and carry serious legal liability under the applicable Personal Data Protection Law.

7. Comprehensive system protection during Flash Sale season with VNIS

VNETWORK is a Vietnamese technology company with over 13 years of experience in cybersecurity and network infrastructure, serving more than 2,000 enterprise customers across multiple industries. In the e-commerce sector, VNETWORK is a trusted partner of many major brands including Tiki, Sendo, Nguyen Kim, Coolmate, CellphoneS, and numerous other mid-to-large scale online retailers. With hands-on experience handling security incidents and infrastructure overloads during major sale seasons, VNETWORK has deep insight into the most fragile points in e-commerce systems during peak hours.

VNIS (VNETWORK Internet Security) is VNETWORK's Web/App/API security and acceleration platform, designed to provide real-time protection against multi-layer DDoS attacks, malicious bots, and application vulnerability exploitation. It applies AI to detect and block abnormal behavior early, while ensuring that legitimate user performance and experience remain uninterrupted. VNIS operates on a dual-layer protection model that is independent yet complementary:

• Layer 1: AI Smart Load Balancing combined with Multi-CDN automatically analyzes and distributes traffic, eliminating abnormal traffic sources before they overload the origin server. A smart cache system serves static content at the edge node closest to the user, while the integrated CDN absorbs volumetric attacks and distributes traffic across a global PoP network without requiring separate deployment.
• Layer 2: WAAP with integrated AI WAF analyzes the behavior of each individual request, building a model of normal behavior for each application to detect deviations even when the attacker is simulating a legitimate browser. OWASP-standard rule sets are continuously updated, blocking all types of DDoS attacks from volumetric to slowloris, while distinguishing malicious bots from legitimate bots. Rate limits are configured per endpoint, with checkout and payment APIs protected far more strictly than standard product pages.

8. Case study: Coolmate maintains stability throughout sale season with VNIS and VNCDN

Coolmate was founded in 2019 with the mission of delivering the best men's fashion shopping experience in Vietnam. As the customer base expanded, Coolmate's technical team recognized a paradox: the more large-scale sale events they organized, the more likely the system was to become unstable at the very moment customers needed it most. Traffic spikes during events like Black Friday slowed page load times, especially for the high-quality product image library that is a key strength of the brand. At the same time, the risk of DDoS attacks and security vulnerabilities such as SQL injection and XSS loomed constantly, capable of disrupting the entire system right at peak revenue hours.

Coolmate evaluated several international providers before deciding to partner with VNETWORK, after recognizing superior cost-effectiveness and flexible customization capability tailored to the specific security requirements of the Vietnamese market. The VNIS solution, with its Multi WAF system comprising multiple global Cloud-WAF clusters, was deployed to rapidly isolate threats as soon as traffic surged. What Hiep, Co-Founder and CTO of Coolmate, valued most was that VNIS integrated seamlessly into the existing system without requiring complex configuration changes, with all operations and management handled by VNETWORK so Coolmate's technical team could concentrate resources on business development projects.

Results after deployment:

• Stable page load speed throughout sales: VNCDN converts images to WebP format, significantly reducing bandwidth consumption. Pages load quickly even during peak hours with thousands of simultaneous users.
• Instant attack detection and isolation: the Multi WAF system blocks DDoS attacks and security vulnerabilities as they emerge, preventing incidents from spreading and impacting the shopping experience.
• Continuous, uninterrupted operation: VNIS integrates seamlessly with all security management handled by VNETWORK, allowing Coolmate's technical team to focus entirely on product development and business expansion.

9. Conclusion

DDoS protection during Flash Sales is not a problem that can be solved on the fly. Businesses must establish traffic baselines, set clear alert thresholds, and deploy the right protection solution at the right layer well before sale day. Accurately identifying real traffic, detecting early attack indicators, and having automated response tools are the three decisive factors in whether an e-commerce system safely navigates peak season. Without any one of the three, risk persists no matter how robust the infrastructure.

Contact VNETWORK for consultation on deploying VNIS suited to your business's scale and model, before the next sale season begins.

• Hotline: 028 7306 8789
• Email: contact@vnetwork.vn

FAQ

1. How is Layer 7 DDoS during Flash Sales different from a standard DDoS attack?

Layer 7 DDoS targets the application layer, simulating legitimate HTTP requests rather than simply saturating bandwidth. During a Flash Sale, this type of attack is especially dangerous because the system is already handling a large volume of real requests, making it very difficult to distinguish from bot attacks without a real-time behavioral analysis solution. Traditional DDoS at Layer 3/4 is easier to identify because it creates a clearly abnormal bandwidth spike.

2. Does rate limiting slow down the experience for real customers?

Rate limiting only affects the experience of real customers if the thresholds are configured too low or applied uniformly across the entire system. When correctly configured, segmented per endpoint, and combined with behavioral analysis, rate limiting only blocks abnormal patterns without impacting normal purchase journeys. VNIS allows fine-tuning of separate thresholds by page type and specific behavior to balance security with user experience.

3. Can VNIS distinguish between automated purchase bots and real customers?

Yes. VNIS uses AI to simultaneously analyze multiple signals: browser fingerprint, navigation behavior, time between requests, the presence of valid cookies and sessions, and historical patterns. Real customers have natural navigation journeys with pauses for reading content, while bots, even when simulating a browser, typically lack this natural variation. VNIS also allows whitelisting of the business's own legitimate bots to prevent mistaken blocking.

4. Do small businesses need DDoS protection during Flash Sales?

Yes, especially during Flash Sales. Hackers do not only target large platforms; smaller e-commerce websites are often easier targets because their security infrastructure is weaker, while the relative damage remains very significant. The cost of deploying CDN and WAF today is accessible for businesses of many sizes, while the cost of handling a DDoS incident and rebuilding brand reputation is typically far higher.

5. Should e-commerce businesses deploy VNIS and VNCDN together or in stages?

VNIS already includes integrated CDN, so most e-commerce businesses can start with VNIS to gain full application-layer security and basic content delivery capability within a single platform. VNCDN is a complementary solution appropriate when a business grows to the point of needing deeper performance optimization, higher bandwidth, or high-quality video streaming requirements. The two solutions are complementary, not substitutes for each other.