Notification Trigger Architecture

Synchronous in-line notification creation ties the success of a user action (like, follow, comment) to the reliability of a secondary side-effect. If the notification INSERT fails — due to a database timeout, connection exhaustion, or a schema constraint — the user sees an error for an action that actually succeeded. Under ISO 25010:2011 reliability, the primary mutation and the downstream notification are separate concerns with different fault tolerances. Coupling them in one request also adds latency: notification creation may involve email dispatch or push webhook calls, blocking the response for hundreds of milliseconds.

Move notification creation out of the request handler and into an async queue using Inngest, BullMQ, or a Vercel background function. The primary mutation returns immediately; the queue worker handles notification delivery independently.

// app/api/posts/[id]/like/route.ts
import { inngest } from '@/lib/inngest'

export async function POST(req: Request, { params }: { params: { id: string } }) {
  const userId = getCurrentUserId()

  const like = await db.like.create({ data: { userId, postId: params.id } })

  // Fire-and-forget — notification failure does not affect the response
  await inngest.send({
    name: 'notification/post.liked',
    data: { likerId: userId, postId: params.id }
  })

  return Response.json({ success: true })
}

The Inngest function handles retries and dead-lettering without coupling them to the HTTP response cycle.