Flyttet tregt arbeid ut av forespørselsbanen og over i en River‑jobbkø — 15 worker‑moduler, 8 planlagte oppgaver og 20 pg_cron‑jobber — slik at en forespørsel returnerer mens arbeidet bak den fortsetter.

Situasjon. Noe arbeid har ingen grunn til å skje mens en bruker venter. Å sende e‑post, bygge en søkeindeks på nytt, generere et dokument, beregne rangeringer på nytt — gjør man noe av det inne i forespørselen, ser brukeren på et lastesymbol for noe vedkommende aldri ba om å se. Gjør man det i en goroutine i stedet, forsvinner det i det øyeblikket prosessen starter på nytt, noe den kommer til å gjøre, midt i en produksjonssetting, uten noe spor av at det noen gang skulle skje.

Oppgave. Bakgrunnsarbeidet trengte et varig sted å bo: en kø som overlever en omstart, prøver på nytt ved feil og kan inspiseres når noe ikke har skjedd.

Handling. Valget falt på River, i stor grad fordi den holder køen sin i PostgreSQL — databasen er allerede det autoritative kildesystemet, så en jobb og radene den berører, committes eller rulles tilbake sammen, og det finnes ingen ekstra infrastrukturdel å drifte og resonnere rundt. Bak den står 15 worker‑moduler og 8 planlagte oppgaver. Under det hele håndterer 20 pg_cron‑jobber vedlikeholdet databasen selv er best egnet til å gjøre: rydde i partisjoner, rotere salter, oppdatere aggregater. Alt som var tregt nok til å merkes, ble flyttet bort fra forespørselsløpet og over på én av de to.

Resultat. Forespørsler returnerer raskt, og det trege arbeidet blir likevel ferdig, med nye forsøk og en synlig historikk når det ikke blir det. Å holde køen i Postgres i stedet for i en egen meldingsmegler er en bevisst begrensning: den skalerer ikke i det uendelige, og ved et visst volum blir den feil svar. For en plattform der flaskehalsen uansett er databasen, var én bevegelig del mindre verdt mer enn spillerom som ikke kom til å bli brukt.