Why this matters now: Same unbounded-memory class as #10 but on a hot, publicly-hit endpoint; will degrade under real traffic.
Problem / What: getLeaderboard (leaderboardController.ts:20-31) does prisma.proof.findMany({ where: { status: 'APPROVED', createdAt... } }) with no limit, builds a Map in JS, then does a second findMany for users. At scale this is both a memory and a latency problem, and the in-JS sort is O(n log n) on a full table scan.
Key Challenges: Pushing aggregation into SQL (window functions / GROUP BY userId with SUM and COUNT, plus a time-window filter) and paginating the top-N without materializing all rows.
Acceptance Criteria:
- Leaderboard computation is a bounded SQL query; memory is independent of total proof count.
- Results (including period filter) match the current implementation on a seeded dataset.
Relevant files/functions: src/controllers/leaderboardController.ts:4-59, prisma/schema.prisma.
Out of scope: Leaderboard caching/denormalization (follow-up).
Labels: advanced, performance
Why this matters now: Same unbounded-memory class as #10 but on a hot, publicly-hit endpoint; will degrade under real traffic.
Problem / What:
getLeaderboard(leaderboardController.ts:20-31) doesprisma.proof.findMany({ where: { status: 'APPROVED', createdAt... } })with no limit, builds aMapin JS, then does a secondfindManyfor users. At scale this is both a memory and a latency problem, and the in-JS sort is O(n log n) on a full table scan.Key Challenges: Pushing aggregation into SQL (window functions /
GROUP BY userIdwithSUMandCOUNT, plus a time-window filter) and paginating the top-N without materializing all rows.Acceptance Criteria:
Relevant files/functions:
src/controllers/leaderboardController.ts:4-59,prisma/schema.prisma.Out of scope: Leaderboard caching/denormalization (follow-up).
Labels: advanced, performance