Unsubscribe triggers async processing job

GDPR Article 7(3) requires that withdrawal of consent be as easy as giving it — a synchronous unsubscribe handler that blocks on ESP API calls and multiple database writes makes withdrawal fragile. CWE-636 (Not Choosing the Least Risky Alternative) applies directly: performing all suppression work inline when a background job is available introduces unnecessary failure modes. CCPA §1798.120 imposes opt-out obligations without exception for system timeouts. If the ESP API is slow or unavailable when a contact clicks unsubscribe, a synchronous handler either times out (swallowing the opt-out entirely) or returns an error the user sees — both outcomes violate the spirit and often the letter of the regulation.

Move suppression cascade logic to a background job. The handler should do exactly two things synchronously — record the request and enqueue the job — then return immediately:

// Route handler in src/app/api/unsubscribe/route.ts
export async function POST(req: Request) {
  const { contactId, scope } = await req.json()

  // Immediate synchronous write (covered by fail-safe-block check)
  await db.contact.update({
    where: { id: contactId },
    data: { optOutStatus: 'pending', optOutRequestedAt: new Date() }
  })

  // Async cascade — retryable, observable, does not block the response
  await queue.add('process-optout', {
    contactId,
    scope,
    requestedAt: new Date().toISOString()
  })

  return new Response(null, { status: 202 })
}

The background worker handles ESP sync, consent record creation, and audit logging with automatic retry on failure.

• ID: compliance-consent-engine.opt-out-processing.async-processing

• Severity: high

• What to look for: When a contact clicks an unsubscribe link or hits an unsubscribe API endpoint, check what happens next. Look at the route handler — does it perform all suppression updates synchronously before returning a 200, or does it enqueue a job and return immediately? Inline processing blocks the HTTP response for the full duration of the suppression cascade (updating all relevant systems), which can time out for large contact graphs or when downstream systems (email platform APIs) are slow. A job queue (BullMQ, Inngest, SQS, Google Cloud Tasks) lets you return a fast 200, retry on failure, and process the cascade reliably.

• Pass criteria: The unsubscribe endpoint enqueues a job (or publishes an event) and returns a 200/302 immediately. Actual suppression cascade runs in a background worker that can be monitored and retried. Count the number of synchronous operations in the unsubscribe handler — no more than 2 should occur before the response is returned (status update + job enqueue).

• Fail criteria: The unsubscribe endpoint performs all database updates, ESP API calls, and suppression sync inline before returning a response. Or the endpoint has no error handling, so a slow ESP API call can cause the unsubscribe to fail silently. Performing all cascade steps synchronously before responding does not count as pass.

• Skip (N/A) when: The application has no email sending capability and no opt-out processing requirement.

• Cross-reference: The Campaign Orchestration & Sequencing Audit's negative-engagement-exit check verifies that unsubscribe events also trigger sequence exits.

• Detail on fail: "UnsubscribeController makes 4 sequential DB writes and 2 ESP API calls inline — average response time 2.3s, failure rate 8% due to Mailchimp API timeouts" or "Unsubscribe endpoint has no error handling — ESP API failures silently swallow the opt-out"

• Remediation: Move processing to a background job:

  // Route handler — fast, reliable
  export async function POST(req: Request) {
    const { contactId, scope } = await req.json()
  
    // Enqueue job and return immediately
    await queue.add('process-optout', { contactId, scope, requestedAt: new Date().toISOString() })
  
    return new Response(null, { status: 202 })
  }
  
  // Background worker — retryable, observable
  queue.process('process-optout', async (job) => {
    const { contactId, scope, requestedAt } = job.data
    await db.consentRecord.create({ data: { contactId, scope, granted: false, source: 'unsubscribe-link', createdAt: new Date(requestedAt) } })
    await emailPlatform.suppressContact(contactId)
    await auditLog.record({ event: 'opt-out-processed', contactId, scope, processedAt: new Date() })
  })