Flyttade långsamt arbete från anropsvägen till en jobbkö i River — 15 workermoduler, 8 schemalagda uppgifter och 20 pg_cron‑jobb — så att ett anrop returnerar medan arbetet bakom det fortsätter.

Situation. Visst arbete har inget att göra medan en användare väntar. Att skicka e‑post, bygga om ett sökindex, generera ett dokument, räkna om placeringar — gör något av det inne i anropet, och användaren sitter och tittar på en snurra för något hen aldrig bad om att få se. Gör det i en goroutine i stället, och det försvinner i samma stund som processen startas om, vilket den kommer att göra, mitt under en driftsättning, utan några spår av att det någonsin var tänkt att ske.

Uppgift. Bakgrundsarbetet behövde ett beständigt ställe att bo på: en kö som överlever en omstart, försöker igen när något misslyckas och går att inspektera när något inte har hänt.

Handling. Valet föll på River, till stor del eftersom den håller sin kö i PostgreSQL — databasen är redan den auktoritativa källan, så ett jobb och raderna det berör committas eller rullas tillbaka tillsammans, och det finns ingen andra infrastrukturdel att driva och resonera kring. Bakom den finns 15 worker‑moduler och 8 schemalagda uppgifter. Därunder sköter 20 pg_cron‑jobb det underhåll som databasen själv är bättre lämpad att göra: att rensa partitioner, rotera salt, uppdatera aggregat. Allt som var tillräckligt långsamt för att märkas flyttades bort från anropsvägen och över till någon av de två.

Resultat. Anrop returnerar snabbt och det långsamma arbetet blir ändå klart, med nya försök och en synlig historik när det inte blir det. Att hålla kön i Postgres i stället för i en dedikerad broker är en medveten begränsning: den kommer inte att skala i all evighet, och vid en viss volym blir den fel svar. För en plattform vars flaskhals ändå är databasen var en rörlig del mindre värd mer än marginal som ändå inte skulle komma till användning.