Auditable draw logic and peak-load payments in competition SaaS
Backend notes from Basecomp on closing entry pools, verifiable winner selection, Stripe under spike traffic, and audit history operators can actually use.
Based on production work on Basecomp . This is engineering perspective, not product documentation.
Competition platforms live or die on trust. Operators need to show that a winner was chosen fairly. Customers want more than a livestream and a congratulations post. Payment providers and partners ask harder questions too, especially when ticket sales spike right before a draw closes.
I was lead backend developer on Basecomp, a multi-tenant Laravel platform for prize competitions. My work covered draw workflows, Stripe under load, entrant records and the admin views operators use to run the business. Draw logic was backend engineering, not a marketing feature bolted on at the end.
Verification matters as much as randomness
Basecomp publishes operator guides on publicly verifiable and provably fair draws in its knowledge centre. That reflects where the industry is heading: customers and regulators want evidence they can inspect later, not only a ceremony on draw night. I am writing here from the engineering side of that same problem.
A draw system should answer, without privileged access: which entries were eligible, when the pool closed, what inputs fed the selection, and whether anyone changed anything after close. If those answers live only in an engineer's head, the product is one dispute away from trouble.
Close the entry pool deliberately
Fair selection starts before randomness. Paid tickets, free postal entries, manual adjustments and late Stripe confirmations all change the eligible set. If entries can drift after you pick a seed, the draw is contestable even when the random step is mathematically fine.
We treated close time as an event with its own record: scheduled close, manual close, sold out, whatever triggered it. Payment state and entry state had to match before selection ran.
Separate commitment from reveal
Verifiable draw designs usually commit to inputs before revealing the winner. Record the seed or equivalent inputs first, then derive the result. That way the outcome cannot be tuned after the fact without leaving an audit trail someone can challenge.
The exact cryptography is a product decision. The engineering requirement is simpler: immutability, traceability, and enough stored detail to reconstruct the draw months later when a customer emails support.
Peak traffic hits when you least want it
Ticket sales cluster in the last minutes before close. Checkout, entry creation, fraud checks and card processing all spike together, exactly when the draw pipeline needs a stable snapshot of who is in the pool.
Stripe can report success while your local entry row is still catching up on a webhook. Draw code cannot run on a pool that has not finished reconciling late payments. The same idempotent webhook handling you would use in ecommerce applies here; only the inventory is tickets instead of SKUs.
Build audit history operators can read
Engineers want immutable logs. Operators want plain language: when the competition closed, how many entries counted, which method selected the winner, whether anyone intervened manually. Both views should come from the same underlying events, not from separate spreadsheets after the fact.
Plan for disputes early
One contested result without evidence hurts the operator and the platform together. Draw logic belongs in the same planning conversations as payments, tenant isolation and load testing, not in a cron script written the week before launch.