Design a Group-Buy Discount Feature

Problem statement

Design a group-buy discount feature for an e-commerce platform. A merchant lists a campaign where the unit price drops once enough distinct users commit to buying within a deadline. If the participant threshold is met before the deadline, every committed user pays the lower group price and the orders finalize. If the threshold is not reached, the group either fails and all committed users are refunded automatically, or committed users fall back to the original price under a consent rule chosen at join time.

This is not a promotion-banner feature. The price of an order depends on the future behavior of strangers. The system must therefore coordinate four things a normal checkout never coordinates: a shared, mutable participant count that thousands of users read while hundreds write it per second; a deadline at which the price becomes final or the commitments unwind; payment semantics that hold money, capture money, or return money depending on an outcome that is unknown at join time; and a real-time progress experience that convinces users to invite friends before the window closes.

Why the problem is distinctive

A flash sale has a fixed price and a first-come constraint. A coupon has a private eligibility check. A group buy has a collective condition: your final price is a function of other people's actions. That introduces three engineering properties that dominate the design.

First, the threshold crossing is a single, contested, exactly-once event. The join that moves a group from three participants to four (when four is the threshold) must atomically flip pricing for all members, and no concurrent join, cancellation, or deadline sweep may observe or produce a contradictory result. This is the same class of race as seat inventory in ticketing, except the resource being guarded is a price state rather than a seat.

Second, money is in motion for an outcome that is uncertain. Depending on the variant, the platform either captures the group price immediately and refunds on failure, or authorizes the card and captures only if the group qualifies. Both variants create refund fan-out at deadline time, authorization-hold expiry management, and reconciliation against the payment provider's settlement reports.

Third, traffic is viral by construction. A campaign's success depends on sharing, so a successful campaign produces correlated bursts: a share lands in a group chat, thirty people open the page within ten seconds, and several join simultaneously. One hot campaign can dominate platform load while everything else is idle.

Public operating baseline versus design assumptions

The category is operationally real and large. Pinduoduo built the modern team-purchase model, where a user opens a group, shares it through WeChat, and friends join within a short window; the company reported roughly 900 million annual active buyers in earnings disclosures before it stopped publishing that metric. Alibaba publicly disclosed order-creation peaks of 583,000 orders per second during its 11.11 festival, which includes group and flash formats run through Juhuasuan. Groupon demonstrated the Western deal-launch pattern: tens of millions of subscribers in its IPO era concentrating on one deal page at launch time. These are cited public signals, not requirements for our fictional system.

For capacity planning, this answer assumes a mature marketplace running group buy as a permanent feature: 50 million monthly active users, 8 million daily active users, 200 concurrent campaigns normally and 2,000 at event peak, 100,000 open groups concurrently, 2,000 joins per second average with a 25x viral peak, and 500,000 group-buy orders per day. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

1. Commerce plane: campaigns, groups, memberships, inventory holds, and the durable state machine that moves a group from OPEN to QUALIFIED to COMPLETED or FAILED.
2. Payment plane: authorization, capture, release, and refund ledgers with idempotent provider calls and paced bulk-refund execution.
3. Real-time plane: participant counters, progress projections, countdown synchronization, and WebSocket or SSE fan-out to browsers and apps.
4. Trust plane: fraud and abuse controls for multi-accounting and bot joins, share-link signing, and compliance for price advertising and payment data.

A strong interview answer keeps these planes separate. The real-time plane may degrade to stale counts without corrupting the commerce plane, and the payment plane may queue refunds during a provider outage without blocking new joins on healthy campaigns.