NWKS Encounter — Registration, Dedup, Roster, and a Campaign Engine Built to Survive Its Own Load
A public registration form dedups against the existing person record, builds the roster automatically, and hands campaign sends to a dedicated worker instead of a request that could time out.
Two annual retreats' worth of registration, follow-up, and roster work with no shared system.
Two annual retreat ministries needed registration, confirmation, and a working roster of who signed up for what — attendee or server, which event, which year — plus a way to reach people afterward and take in testimonies. That is dedup work, CRM work, and campaign-send work, and none of it holds together as a spreadsheet and an inbox once a form actually gets used.
Because it's two genuinely separate ministries, the system also had to keep their people, registrations, and communications apart from each other on every table, without running two separate codebases.
A registration flow that dedups into one person record, and a campaign engine that respects its own CPU budget.
A public, bot-protected registration form matches against existing people — exact email first, then fuzzy last-name plus phone or city — before deciding whether to create a new person or update an existing one. It then writes a registration for that event and role, queues a confirmation, and the person appears on the admin roster immediately.
The admin surface covers the rest of the operational work: a dashboard, attendee and server rosters, a standing-interest list, per-person history with duplicate merging, events, an email center with campaigns, segments, and templates, a testimonies board, a forms editor, and team roles, sitting behind passkey/WebAuthn 2FA with a recovery ladder.
The email center is where the architecture had to change shape. A synchronous send to 2,402 recipients took 67 seconds — long enough to blow the platform's per-request CPU budget. The fix was a dedicated, always-on cron worker that drains scheduled campaigns in bounded chunks instead of trying to send a whole campaign inside one request. That's a load characteristic that drove the design, not a marketing campaign that went out to real subscribers — production email sending is explicitly disabled right now. A separate inbound worker parses raw MIME for replies, and two ministries share the codebase with every table partitioned per program.
How a registration becomes a roster entry, and how campaigns actually send.
Public registration form, bot-protected
Dedup: exact email match first, then fuzzy last-name plus phone/city
Creates or updates the person, then writes a registration for event and role
Confirmation queued; entry appears on the admin roster
Dashboard, attendee/server rosters, standing-interest list, per-person history with merging
Events, email center (campaigns, segments, templates), testimonies board, forms editor, team roles
Dedicated always-on cron worker drains scheduled campaigns in bounded chunks
Separate inbound email worker parses raw MIME
Passkey/WebAuthn 2FA with a recovery ladder
Two ministries, one codebase, partitioned per program on every table
Registration and CRM
- Exact-email dedup, then fuzzy last-name + phone/city match
- Create-or-update person, then event + role registration
- Confirmation queue, admin roster, duplicate merging
- Standing-interest list and per-person history
Campaign infrastructure
- Dedicated cron worker drains scheduled sends in bounded chunks
- Built after a synchronous 2,402-recipient send took 67 seconds
- Separate inbound worker parses raw MIME for replies
- Email provider: Resend
Outcomes the engagement actually produced.
756 API tests cover registration, dedup, roster, and CRM behavior, with a separate admin test suite.
A synchronous send to 2,402 recipients took 67 seconds, which is what made a dedicated cron worker necessary instead of sending inside a single request.
Two separate retreat ministries run on one codebase, with people, registrations, and communications kept apart on every table.
WebAuthn/passkey authentication protects the admin CRM, with a recovery ladder for lost devices.
Running event registration through a form and a spreadsheet?
Preisser Solutions builds registration, dedup, and CRM systems that hold up past the first big send. Scoping begins with a conversation about your events and your list.