Relationship State Resolution
Why it matters
Resolving follow status with a separate query per user card is a textbook N+1 problem. A feed page showing 50 user cards fires 50 individual isFollowing database calls — each a round-trip that adds 5–20ms of latency in a cloud deployment. At 100ms/page the cumulative cost is 5 seconds of blocked rendering. Under ISO 25010:2011 performance-efficiency, this is a structural scalability defect: response time degrades linearly with the number of items displayed, making any growth in user density directly punishing.
Severity rationale
Medium because the performance impact is proportional to page size and grows predictably, but it degrades user experience gradually rather than causing immediate failures.
Remediation
Preload follow status alongside the user list in a single query, or use DataLoader to batch all isFollowing checks for a given page render into one database round-trip.
// lib/db.ts — preload approach
export async function getUsersWithFollowStatus(viewerId: string, limit: number) {
const users = await db.user.findMany({
take: limit,
select: {
id: true,
name: true,
avatar: true,
followers: {
where: { followerId: viewerId },
select: { id: true }
}
}
})
return users.map(u => ({
...u,
isFollowing: u.followers.length > 0,
followers: undefined
}))
}
This collapses N+1 queries into a single JOIN, regardless of how many user cards are rendered.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Social Features & Engagement Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · performance-efficiency — Time Behaviour
Taxons
History
- 2026-04-18·v1.0.0·Initial import from community-social-engagement·automated