High-concurrency registration flows

These flows ran on portals where users registered for draws under time pressure. The same release had to hold under bursts of traffic while preventing duplicate or inconsistent entries.

The risk was not only load. The system also had to stop duplicate registrations, repeated submissions, invalid data combinations, and edge cases created by concurrent requests.

Because the stack included WordPress and existing databases, the safeguards had to work across frontend, backend, and storage rather than in one layer only.

I built the registration flow spec-first — the deduplication, idempotency and persistence rules were defined before any code — so the concurrency edge cases surfaced in the spec, not in production.

I enforced validation on both sides of the request, deduplication via DB constraints, idempotency on the write path, and rate limiting at entry — so concurrent and repeated submissions wouldn't create double entries, but legitimate retries by the same user still went through.

The goal was to reject bad registrations as early as possible, keep persistence rules strict, and leave enough signal in production to debug incidents quickly.

The draw flows moved from ad-hoc validation to controlled registration paths with deduplication, idempotent writes, rate limiting, and clearer operational signals.

That reduced inconsistent records, repeated entries, and manual cleanup during high-demand windows, while keeping legitimate retries from the same user working.