Follow/Unfollow Transactional Logic

Non-transactional follow mutations create race conditions (CWE-362) that permanently corrupt follower counts — a user can end up showing 5,000 followers in their count column while the actual follows row count is 4,200. Worse, without a unique constraint on (followerId, followedId), concurrent double-taps produce duplicate follow rows that inflate counts and break feed queries. Self-following bypasses are both a data integrity failure and an embarrassing product defect. These are not edge-case concerns: follow endpoints are hammered at scale, making TOCTOU collisions routine.

Add @@unique([followerId, followedId]) to your Prisma Follow model to enforce deduplication at the database level, then wrap every follow mutation in a db.$transaction that updates both the relationship and the denormalized counts atomically.

// app/api/users/[id]/follow/route.ts
export async function POST(req: Request, { params }: { params: { id: string } }) {
  const userId = getCurrentUserId()
  if (userId === params.id) {
    return Response.json({ error: 'Cannot follow yourself' }, { status: 400 })
  }

  await db.$transaction([
    db.follow.create({ data: { followerId: userId, followedId: params.id } }),
    db.user.update({ where: { id: userId }, data: { following_count: { increment: 1 } } }),
    db.user.update({ where: { id: params.id }, data: { followers_count: { increment: 1 } } })
  ])

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

The unique constraint ensures a duplicate follow throws a Prisma P2002 error before the transaction commits, eliminating the race window entirely.