Designing a Cost‑Controlled “Cut‑One‑Knife” Promotion Engine for Massive Concurrency

In a mock interview scenario, the candidate is asked to design a "cut‑one‑knife" activity where users help each other reduce the price of a phone (cost ¥2000) while the platform must not lose money despite high concurrency and malicious bots.

Core Algorithm: Value‑Based Dynamic Pricing

The system does not use random cuts; it assigns a user value weight to each helper and calculates the cut amount accordingly. New users (high value) get a weight of 10.0 and cut ¥20, old users get 0.1 weight and cut ¥0.2, and bot accounts receive a weight of 0.001 cutting ¥0.01. The goal is to accumulate a total CAC (customer acquisition cost) of ¥200 before granting the phone.

Zeno Paradox‑Inspired Convergence

When the progress reaches 99%, the engine enters a "convergence mode" where the remaining amount is treated as a mathematical limit. The residual ¥1 is split into an infinite series (0.5 + 0.2 + 0.1 + ...), approaching zero but never reaching it, preventing the system from giving away the phone for free.

public BigDecimal cut(User helper) {
    // 1. Get helper's weight (0.01 ~ 10.0)
    BigDecimal weight = UserProfileService.getWeight(helper.getId());
    // 2. Base amount = remaining * decay rate
    BigDecimal base = remainAmount.multiply(DECAY_RATE);
    // 3. Final cut = base * weight
    // 4. Minimum cut = 1 cent (10000 micro units)
    return calculate(base, weight);
}

Architecture for High Concurrency

The algorithm guarantees cost control; the infrastructure must guarantee stability.

1. Integer‑Based Money Storage

Store monetary values as integers representing micro‑units (1 ¥ = 1,000,000 µ) in Redis. Use Long and Lua DECRBY for nanosecond‑level atomic decrements, eliminating floating‑point precision issues.

2. Mitigating Hot‑Key Pressure

When a popular influencer shares the link, a million helpers may hit the same Redis key. The solution is a local cache (LocalCache) on the JVM to filter out 90% of invalid requests and a message‑queue (MQ) to smooth write spikes, showing a "cutting…" placeholder on the front end.

Core Anti‑Fraud Measures

To prevent bots from draining the budget, the system combines device fingerprinting (gyroscope, press area) with behavioral biometrics. Detected bots receive a "risk‑downgrade" where the front end shows success but the backend deducts zero.

Forced Turing Tests at Critical Points

At the final ¥0.01 or ¥0.001 stages, the user must solve a sliding‑puzzle or character‑selection captcha, which blocks 99% of automated scripts because solving services cannot keep up with real‑time user interaction.

Why the Final Reward Becomes “Coins”

Database stores amounts down to 1 µ, but the UI can only display two decimal places. When the remaining amount is below 0.01 ¥, the system switches to a "virtual‑item" mode, converting the tiny residual into coins or fragments, effectively extending the progress bar and keeping users engaged.

Interview Answer Template

Algorithm layer: use user‑value weight and Zeno‑paradox‑based convergence.

Storage layer: Redis Long (micro‑unit) with Lua scripts for precision.

Risk layer: device‑fingerprint + key‑node captchas to block bots.

Product layer: when precision runs out, switch to "unit‑switch" (coins/fragments) to avoid technical dead‑ends while maintaining legal compliance.

Understanding that the system’s essence is a precise calculation of human behavior, not merely a technical trick, helps engineers write code that drives business value.