Architectural Decisions

“production runs TWO clubfinder-backend instances (clubfinder-backend + clubfinder-backend-2, blue/green). Both run the every-minute NestJS @Cron schedulers independently. ensureAlwaysPremium() (always-premium test avatars) does check-then-insert: read status, INSERT a fresh subscription if the user has no active one. After a data wipe, both instances see "no active sub" in the same tick and both INSERT -> duplicate active rows (observed 2026-07-02:”

“issue #128 repoints the dashboard analytics off dj_sets onto the staff_weekly_assignments_log archive: R4a (completed-set count), R4c (no-show count), R5 (dj_club_history cron) all scan the log filtered by (club_id, status='complete', archived_at range). staff_weekly_assignments_log was created in migration 096 as a bare LIKE copy”

“#146 Option B repoints DJ / Host / Entertainer Set History (#145) off dj_sets onto this archive log (the single source of truth for completed sets going forward). The log stores club_id only — no FK to clubs, no denormalized name — so a hard-deleted club (the quarterly cull) would leave completed-set history unrenderable. Mirror the dj_sets.club_name snapshot (migration 110).”

“#146 repointed Set History (#145) onto staff_weekly_assignments_log. Existing completed sets live in the retired dj_sets store, so without this backfill a performer's history would read empty until the completion cron accumulates new rows. This copies each completed dj_set into the log — one row per attributed staff role (dj / host / entertainer) — preserving counts.”

“#81 moved the write path, #128 repointed the live readers, #125 P1/P2 repointed the SSR readers, and the admin Genre Calendar (last reader) was retired in #176. dj_sets now has ZERO readers/writers in application code (once the paired code change lands — see "Deploy order" below). This drops the table and every object that depends on it.”

“Issue #145 (DJ Completed Set History) shows a DJ's completed-set counts per club on the profile pages, reading the club name off the set row itself. dj_sets stores only club_id, with NO foreign key to clubs and no denormalized name — so when a club is hard-deleted (the quarterly cull), the completed-set history loses its club name and becomes unrenderable.”