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.