Context
The public form gathers project constraints and attribution so the private CRM can evaluate the enquiry. Visitors may retry if the network fails before they see confirmation.
The constraint
A synchronous notification dependency can make a successful lead write look like a failed enquiry. A careless retry can create a second lead, while analytics code can introduce unrelated failures.
The approach
Lead creation and outbox enqueueing share a transaction. A submission key and payload hash make matching retries idempotent. A worker claims notification jobs, signs requests and applies bounded retries after persistence.
Architecture
- 01Visitor submits a qualified brief
- 02Validated, idempotent API operation
- 03Lead + notification job commit together
- 04Worker delivers a signed event
- 05Private CRM follow-up
Decisions and tradeoffs
Success is shown only after the backend confirms persistence. Analytics emits a browser event after that acknowledgement and remains optional.
Notification delivery is at least once. The receiving endpoint must use the event ID as an idempotency key. Failed delivery retains the lead and a retryable job.
Implementation
The form preserves input on error. First-touch campaign fields are stored for a limited browser session and carried to the saved lead; confirmation contains a reference without exposing the brief.
Evidence and outcomes
The integration checks cover matching retries, conflicting keys, consent validation, persisted attribution, notification failure and recovery. They do not claim a production conversion rate.
Stack
NestJS
PostgreSQL
Prisma
Next.js