Turning 618 Sales Uncertainty into Certainty: Cloud‑Native Best‑Practice Guide

Introduction

Large‑scale sales events such as the 618 promotion bring many uncertainties—traffic spikes, unpredictable user behavior, security attacks, rapid R&D changes, and potential failures. Converting these unknowns into deterministic conditions is essential for a smooth operation.

Key Challenges

Uncertain traffic volume and patterns.

Unpredictable user actions (e.g., flash sales, coupons).

Potential security attacks and bot traffic.

Risk of code changes during the event.

Impact of system failures on a wide user base.

Preparation Methodology

The preparation follows four pillars: capacity assessment, pre‑plan (pre‑plan), pre‑heat, and rate limiting. Achieving these pillars transforms uncertainty into deterministic conditions, allowing the system to handle traffic surges gracefully.

Goal Determination

Typical goals include supporting peak traffic for a specific service, achieving cost optimization (e.g., 30% reduction), and delivering a smooth user experience. Cost considerations involve Nacos, cloud‑native gateways, and the number of application instances, while efficiency is boosted by PTS full‑link load testing and MSE Switch dynamic configuration. Stability is ensured through MSE service governance’s end‑to‑end traffic control and lossless scaling.

Capacity Assessment

Assess both performance baselines and budget constraints. Evaluate:

Performance and optimization to guarantee application stability.

Business and system changes.

Full‑link load‑test models based on business scenarios.

Capacity limits, keeping utilization around 60% and enabling elastic scaling.

Performance Testing with PTS

PTS offers a SaaS‑based, zero‑install load‑testing platform with features such as:

Full SaaS deployment, no extra installation.

Zero‑install cloud recorder suitable for mobile apps.

Data‑factory for API request parameter formatting without coding.

Visual orchestration of complex scenarios, supporting login sharing, parameter passing, business assertions, and advanced directives.

Multiple RPS/concurrency modes and dynamic second‑level traffic adjustment.

Rich reporting and real‑time metrics.

After identifying bottlenecks, the system is optimized iteratively.

Pre‑heat Strategies

Pre‑heat reduces latency by moving critical data closer to the application:

Data pre‑heat: Load high‑frequency data (shopping carts, coupons) into cache before the event.

Application pre‑heat: Gradually increase traffic to newly launched micro‑service instances based on weighted start‑time, ensuring smooth scaling.

Connection pre‑heat: Establish connection pools (e.g., Redis JedisPool) ahead of traffic to avoid latency spikes. Example code:

org.apache.commons.pool2.impl.GenericObjectPool#startEvictor</code><code>protected synchronized void startEvictor(long delay) {</code><code>    if(null != _evictor) {</code><code>        EvictionTimer.cancel(_evictor);</code><code>        _evictor = null;</code><code>    }</code><code>    if(delay > 0) {</code><code>        _evictor = new Evictor();</code><code>        EvictionTimer.schedule(_evictor, delay, delay);</code><code>    }</code><code>}

Parallel Class Loading

Enabling parallel class loading (JDK 7+ via ClassLoader.registerAsParallelCapable) reduces lock contention when multiple threads load different classes. MSE Agent can activate this capability without modifying the application server.

protected static boolean registerAsParallelCapable() Registers the caller as parallel capable. The registration succeeds if and only if all of the following conditions are met: 1. no instance of the caller has been created 2. all of the super classes (except class Object) of the caller are registered as parallel capable

Flow Control and Rate Limiting

Flow control protects micro‑service stability by limiting QPS per interface. Two typical scenarios are addressed:

Downstream total‑call control: Service A limits calls to Service B to a shared quota (e.g., 600 QPS) using cluster‑wide flow control.

Entry‑point request control: Gateways (Nginx, Ingress, Spring Cloud Gateway, Zuul) enforce global thresholds to shield backend services.

MSE service governance provides cluster flow control with features such as professional protection, hotspot isolation, dependency isolation, system‑level protection, second‑level traffic analysis, and flexible SDK/Agent/container integration.

Conclusion

By following the outlined methodology—capacity assessment, rigorous performance testing, systematic pre‑heat, and precise flow control—organizations can transform the inherent uncertainties of large‑scale sales events into predictable, manageable conditions, ensuring cost‑effective, stable, and high‑performance operation.