apps/backend/src/app/api/latest/internal/metrics/route.tsx (2)

36-41: Extra query added for scaling calculation.

The totalUsers count query is necessary to calculate the scaling factor. While this adds an extra database round-trip, the performance impact should be minimal, and the approach is clear and maintainable.

If optimization becomes necessary, consider combining the count with the fetch using a window function or CTE, though the current approach prioritizes clarity.

---

48-49: Document the deterministic sampling trade-off.

The orderBy: { projectUserId: "asc" } approach ensures consistent sampling (beneficial for caching), but introduces bias by always selecting the earliest users. If geographic distribution has shifted over time, this could underestimate or miss countries where users joined more recently.

Consider one of these approaches:

1. Add documentation explaining the trade-off between cache consistency and sampling accuracy.

2. Use hash-based sampling for deterministic yet more representative results:

// Example: Sample ~10% deterministically across all user IDs
const samplingPercentage = Math.min(100, Math.ceil((MAX_USERS_FOR_COUNTRY_SAMPLE / totalUsers) * 100));
const users = await prisma.$queryRaw`
  SELECT "projectUserId"
  FROM "ProjectUser"
  WHERE "tenancyId" = ${tenancy.id}::UUID
    AND ${includeAnonymous} OR "isAnonymous" = false
    AND MOD(ABS(HASHTEXT("projectUserId"::text)), 100) < ${samplingPercentage}
  LIMIT ${MAX_USERS_FOR_COUNTRY_SAMPLE}
`;

This maintains determinism while avoiding chronological bias.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro