Events & sport
Northern Marathon 2026 Registration System
Registration, payment and race-day check-in for an AIMS member, World Athletics certified race in Saidpur — built to survive the opening-minute stampede without selling a place twice or losing a payment.
At a glance
- Every published race category, with no place sold twice
- Sold out
- Registrations migrated from the organiser's WooCommerce store
- 1,077
- Race-day kit scanning keeps working without a connection
- Offline
What did BetterSoftZ build for Northern Marathon?
BetterSoftZ built the complete registration system for Northern Marathon 2026, organised by Saidpur Runners: the public race website, a virtual waiting room for the first-come-first-served opening, SSLCommerz payments, automatic BIB numbers and QR e-tickets, an admin panel, and an offline-capable scanner app for race-day kit collection. Every published category sold out with no place oversold.
The need
Northern Marathon opens registration first come, first served. Runners arrive in the same minute it opens, many on mobile data behind shared carrier IP addresses, and the previous WordPress and WooCommerce setup was not built for that. An overload at opening means pages that never load, places sold twice, and payments taken for registrations that never completed — each one a support case for a small volunteer organising team.
A waiting room instead of a crash
Runners who arrive at opening join a queue rather than hammering the registration form. Their position is stable and visible, and the status check is cached at the edge by Cloudflare so the queue itself creates almost no load. The system admits people at a controlled rate, bounded by the places that remain, and stops admitting the moment a category sells out. While they wait, runners can fill in their form so the paid part of the flow takes seconds.
Before opening day we ran a scripted stampede against the real category set. It found two launch-day bugs, both fixed before a single runner arrived.
No place sold twice
Overselling is handled by two layers. Redis turns requests away instantly when a category is full. PostgreSQL makes the final decision with a conditional update and a check constraint, so the database cannot record more places than exist — whatever happens in the layers above it.
Payments that reconcile themselves
Payments go through SSLCommerz. The gateway’s callback, the browser redirect, a background reconciliation job and the hold-expiry timer can all report the same payment, so every path re-checks the transaction with the gateway and is idempotent. A late payment either uses a small held-back buffer or is refunded automatically.
After payment: accounts, BIBs and e-tickets
Paying creates the runner’s account. Once they set a password and verify their phone, they receive a BIB number, a signed QR code and a PDF e-ticket. Email and SMS go out through an outbox with retries, so a provider outage delays a message instead of losing it. Runners can also sign in with a one-time email code.
Race day, offline
Kit collection runs on a scanner app installed on volunteers’ phones. It keeps scanning without a connection and syncs when coverage returns. The database enforces one collection per item per runner, so a T-shirt or medal cannot be handed out twice from two different desks.
Moving off WordPress
The organiser’s existing WooCommerce registrations were migrated into the new system: 227 registrations for the 2026 race and 850 from the 2025 Northern Half Marathon, which now appears on a public past-events page. The import scripts are idempotent and only ever add records, so they could be re-run safely. Orders that needed a human decision were listed for the organiser instead of being guessed at.
Frequently asked questions
How do you stop a race from overselling when registration opens?
Two checks. Redis rejects requests instantly once a category is full, and PostgreSQL has the final say with a conditional update and a database constraint that makes a negative stock count impossible. Even if every other safeguard failed, the database cannot record a place that does not exist.
What happens if a runner pays after their slot has expired?
Every payment confirmation, whether it arrives from the gateway's callback, the browser redirect or the reconciliation job, is re-validated with SSLCommerz and processed once. A late payment either takes a place from a small held-back buffer or is refunded automatically, so nobody is charged without a registration.
Can the same approach be used for concerts, conferences or exams?
Yes. The waiting room, inventory and payment pieces do not know they are selling race places. Any event that opens a limited number of seats at a fixed time has the same problem, and our event management system is built on the same design.
Have something like this to build?
Tell us what you are building. We will tell you in writing what the first step costs and what it produces.