Operations 7 min read

Why Our First Flash‑Sale Crashed and the Operations Lessons We Learned

The first launch of Taijie Mall’s flash‑sale site crashed due to uncompressed images, a missing purchase button, and a refresh avalanche, but by isolating services and applying capacity‑planning formulas we identified key bottlenecks, implemented CDN and simplifications, and achieved a much smoother second launch.

MaGe Linux Operations
MaGe Linux Operations
MaGe Linux Operations
Why Our First Flash‑Sale Crashed and the Operations Lessons We Learned

We built the Taijie Mall to sell the WEBOX product, a simple one‑item flash‑sale site that required online‑to‑offline fulfillment.

On June 24 the first launch failed: a programming bug prevented the purchase button from appearing, and the homepage contained many large, uncompressed images, causing massive concurrent connections, 502 errors and a server‑side avalanche.

Fortunately the storefront server was isolated from the main site, so the sales service remained reachable via a manually shared URL, allowing us to sell about 1,000 units by 1:30 pm instead of the expected ten minutes.

We identified three failure points: heavy image‑laden pages, the missing purchase button, and the avalanche of refresh requests.

Successes included the separation of the main site and the sales service, which prevented a total outage.

Our improvements for the next launch were: simplify the purchase page with minimal images, avoid dynamic requests after the countdown, and serve all static assets through a CDN.

We also reflected on how to design a high‑concurrency website, estimating bandwidth, concurrent connections and memory based on page views (PV), resources per page and average resource size.

Formulas: Bandwidth = PV × resources per page × average resource size; Concurrent connections = Bandwidth ÷ average download speed = PV × resources per page × average download time.

Example: PV = 100 /s, 30 resources per page, 100 KB each → bandwidth = 300 MB/s, average download speed = 100 KB/s → 3,000 concurrent connections, requiring roughly 30 MB memory.

We discussed that bandwidth, connections and memory are hard to simulate with load testing, but can be estimated from real PV. Dynamic request capacity should be measured via stress testing to find the lowest QPS, which becomes the system’s bottleneck; scaling, code optimization or overload protection can then be applied.

After applying these lessons, the second flash‑sale on July 1 performed much better, demonstrating that learning from failure leads to success.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

e‑commerceOperationshigh concurrencycapacity planningwebsite performanceflash sale
MaGe Linux Operations
Written by

MaGe Linux Operations

Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.