Why Modern Internet Architecture Gets Complex and How to Master Flash‑Sale Systems

1. Why Internet Architecture Is Getting More Complex?

Early systems served only a few users, mainly internal admin tools, so they didn't need to consider many aspects such as concurrency, indexing, sharding, caching, overload protection, security policies, disaster recovery, idempotency, or multi‑active architectures.

Low traffic, no concurrency concerns

Small data, no index optimization or sharding

Distributed access, no caching or overload protection

Non‑critical data, no security or backup requirements

Repeatable submissions, no idempotency needed

Allow occasional downtime, no need for active‑active architecture

With the rapid growth of internet users, these simple designs can no longer handle the surge in traffic, prompting the emergence of sophisticated architectural solutions.

2. What Is Flash‑Sale / Auction Business?

Flash‑sale (秒杀) business has become common with e‑commerce expansion. It differs from regular business in that a small amount of data is accessed and purchased by many users simultaneously, creating a burst of high‑frequency reads and writes, often called a "herd request".

2.1 Regular Business

Personal information such as registration details, public accounts, friend lists – typically 1:1 and not widely visible.

Social feed content – 1:n, visible to many friends.

2.2 Flash‑Sale / Auction Business

Typical flash‑sale scenarios:

Train ticket release before Chinese New Year, where millions of requests may arrive instantly.

Limited‑edition product launches that sell out within a second.

Technical challenges include:

Massive instantaneous traffic stressing the access, application, and data layers.

Ensuring atomic increments, order fairness, and preventing overselling.

Maintaining data security, preventing attacks, abuse, and ensuring idempotency.

Avoiding deadlocks when using concurrency controls.

Therefore, designing an efficient flash‑sale architecture remains a timeless topic.

3. Optimization Strategies

Below are key improvement points for flash‑sale systems, such as dynamic cluster scaling, traffic control, elastic scaling, and intelligent rate limiting (see the referenced article for details).

3.1 Filter Invalid Requests

Eliminate invalid requests as early as possible, preferably on the web front‑end or app client, to reduce server load. Common intercepts include:

Unauthenticated request interception

Duplicate submission interception (disable button until response or timeout)

Frequent submission interception (e.g., max 100 requests per minute per user)

Captcha interception (prevent bots and attacks)

Eligibility interception (e.g., user level, account age, blacklist)

3.2 Server + Cache Layer for Efficient Atomic Operations

Caching hot data dramatically improves performance and reduces database load. Redis can handle 100k+ operations per second on a single node, and scales further with clusters.

Atomic counters in Redis ensure accurate flash‑sale counts using commands such as INCR , INCRBY , DECR , and DECRBY . These operations are indivisible, guaranteeing consistency.

<code># Increment sold count by 1000
INCRBY cullinan_counter 1000

# Retrieve current sold quantity
GET cullinan_counter
# => 1000

# If exceeds limit, flash‑sale fails</code>

Ordered request handling can be achieved with Redis Streams. Use XADD to push messages into a stream, which assigns a unique ID.

<code>XADD mystream * field1 value1 field2 value2</code>

If only 1000 items are available, requests beyond that should be rejected before entering the queue.

Extended reading: the author's Redis series (★ Redis 24‑article collection).

3.3 Data Layer as Final Safeguard

After front‑end filtering and cache guarantees, the database only needs to store the fixed inventory quantity (e.g., 1000). The load is minimal, and the database can handle it easily. Use constraints or triggers to verify that the sold count does not exceed the limit.

3.4 Global Business, Unit‑Based Isolation

For worldwide sales, cross‑region latency can cause unfairness (e.g., European users missing out). The common solution is unit‑based isolation: deploy separate cache and data clusters per region, each managed by a unified configuration center.

A/B testing centers use such isolated caches and data structures, ensuring that each unit operates independently. Flash‑sale systems should avoid cross‑region, cross‑datacenter designs to prevent user unfairness.

4. Conclusion

Intercept invalid requests early on the front‑end to reduce server pressure.

Leverage caching for high‑performance lookups, atomic counters, and ordered queues.

Use the data layer as a final safeguard with constraints or triggers.

Apply the divide‑and‑conquer principle: isolate units to avoid centralized bottlenecks.