Cron + databasmönster: bakgrundsjobb utan en kö

Problemet: schemalagt arbete utan extra infrastruktur

De flesta appar behöver att arbete körs senare eller enligt schema: skicka uppföljningsmejl, köra en nattlig fakturakontroll, rensa gamla poster, bygga om en rapport eller uppdatera en cache.

I början är det frestande att lägga till ett fullfjädrat kö-system eftersom det känns som det "rätta" sättet att göra bakgrundsjobb. Men köer tillför rörliga delar: en tjänst till att köra, övervaka, deploya och felsöka. För ett litet team (eller en ensam grundare) kan den extra tyngden sakta ner dig.

Så den verkliga frågan är: hur kör du schemalagt arbete pålitligt utan att starta mer infrastruktur?

Ett vanligt första försök är enkelt: lägg till en cron-post som träffar en endpoint, och låt den endpointen göra arbetet. Det fungerar tills det inte gör det. När du har fler än en server, en deploy vid fel tidpunkt, eller ett jobb som tar längre än förväntat, börjar du se förvirrande fel.

Schemalagt arbete går vanligen sönder på några förutsägbara sätt:

• Dubbelkörningar: två servrar kör samma uppgift, så fakturor genereras två gånger eller mejl skickas dubbelt.
• Förlorade körningar: en cron-anrop misslyckas under en deploy och ingen märker det förrän användare klagar.
• Tysta fel: jobbet kastar ett fel en gång och körs aldrig igen eftersom det inte finns någon retry-plan.
• Partiellt arbete: jobbet kraschar halvvägs och lämnar data i ett konstigt tillstånd.
• Ingen revisionslogg: du kan inte svara på "när kördes detta senast?" eller "vad hände i natt?"

Cron + databas-mönstret är en mittenväg. Du använder fortfarande cron för att "väcka" enligt schema, men du lagrar jobbavsikt och jobbstatus i din databas så systemet kan koordinera, retry:a och registrera vad som hände.

Det passar bra när du redan har en databas (ofta PostgreSQL), ett litet antal job-typer och du vill ha förutsägbart beteende med minimal ops. Det är också ett naturligt val för appar byggda snabbt på moderna stackar (till exempel React + Go + PostgreSQL).

Det är inte en bra passform när du behöver mycket hög genomströmning, långkörande jobb som måste streama status, strikt ordning över många job-typer eller tung fan-out (tusentals underuppgifter per minut). I de fallen betalar sig ett riktigt kö-system och dedikerade workers oftast.

Kärnidén i klartext

Cron + databas-mönstret kör bakgrundsarbete enligt schema utan att köra ett fullständigt kö-system. Du använder fortfarande cron (eller en scheduler), men cron bestämmer inte vad som ska köras. Den väcker bara en worker ofta (en gång per minut är vanligt). Databasen bestämmer vilket arbete som är förfallet och ser till att bara en worker tar varje jobb.

Tänk på det som en delad checklista på en whiteboard. Cron är personen som går in i rummet varje minut och säger "Behöver någon göra något nu?" Databasen är whiteboarden som visar vad som är förfallet, vad som redan är taget och vad som är klart.

Delarna är enkla:

• En enda scheduler-trigger kör ofta.
• En jobs-tabell håller vad och när (due time), plus status och försöknummer.
• En eller flera workers pollar tabellen, gör anspråk på ett jobb och utför arbetet.
• Anspråk använder ett databaslås så två workers inte kan ta samma rad.
• Databasen förblir sanningskällan för vad som kördes, vad som misslyckades och vad som ska retry:as.

Exempel: du vill skicka fakturapåminnelser varje morgon, uppdatera en cache var 10:e minut och rensa gamla sessioner varje natt. Istället för tre separata cron-kommandon (var och en med sina egna överlapp och felmod), lagrar du jobbposter på ett ställe. Cron startar samma worker-process. Workern frågar Postgres, "Vad är förfallet just nu?" och Postgres svarar genom att låta workern säkert göra anspråk på exakt ett jobb åt gången.

Det här skalar gradvis. Du kan börja med en worker på en server. Senare kan du köra fem workers över flera servrar. Kontraktet är detsamma: tabellen är kontraktet.

Tankesättet är enkelt: cron är bara väckarklockan. Databasen är trafikpolisen som bestämmer vad som får köras, registrerar vad som hände och ger dig en tydlig historik när något går fel.

Designa jobs-tabellen (ett praktiskt schema)

Detta mönster fungerar bäst när din databas blir sanningskällan för vad som ska köras, när det ska köras och vad som hände senast. Schemat är inte fancyt, men små detaljer (låsfält och rätt index) gör stor skillnad när belastningen växer.

En tabell eller två?

Två vanliga tillvägagångssätt:

• En kombinerad tabell när du bara bryr dig om det senaste tillståndet för varje jobb (enkelt, färre joins).
• Två tabeller när du vill ha en ren separation mellan "vad detta jobb är" och "varje gång det kördes" (bättre historik, lättare felsökning).

Om du förväntar dig att felsöka ofta, behåll historiken. Om du vill ha den minsta möjliga uppsättningen, börja med en tabell och lägg till historik senare.

Ett praktiskt schema (två-tabellsvariant)

Här är en PostgreSQL-vänlig layout. Om du bygger i Go med PostgreSQL mappar dessa kolumner rent till structs.

-- What should exist (the definition)
create table job_definitions (
  id            bigserial primary key,
  job_type      text not null,
  payload       jsonb not null default '{}'::jsonb,
  schedule      text,                      -- optional: cron-like text if you store it
  max_attempts  int not null default 5,
  created_at    timestamptz not null default now(),
  updated_at    timestamptz not null default now()
);

-- What should run (each run / attempt group)
create table job_runs (
  id            bigserial primary key,
  definition_id bigint references job_definitions(id),
  job_type      text not null,
  payload       jsonb not null default '{}'::jsonb,
  run_at        timestamptz not null,
  status        text not null,             -- queued | running | succeeded | failed | dead
  attempts      int not null default 0,
  max_attempts  int not null default 5,

  locked_by     text,
  locked_until  timestamptz,

  last_error    text,
  created_at    timestamptz not null default now(),
  updated_at    timestamptz not null default now()
);

Några detaljer som sparar problem senare:

• Håll job_type som en kort sträng du kan routa på (t.ex. send_invoice_emails).
• Spara payload som jsonb så du kan utveckla den utan migrationer.
• run_at är din "nästa förfallotid". Cron (eller ett scheduler-skript) sätter den, workers konsumerar den.
• locked_by och locked_until låter workers göra anspråk på jobb utan att trampa varandra på tårna.
• last_error bör vara kort och människoläsbar. Lägg stacktraces någon annanstans om du behöver dem.

Index du kommer vilja ha

Utan index kommer workers skanna för mycket. Börja med:

• Ett index för att snabbt hitta förfallet arbete: (status, run_at)
• Ett index för att hjälpa till att upptäcka utgångna leases: (locked_until)
• Valfritt: ett partiellt index för bara aktivt arbete (t.ex. status i queued och failed)

Dessa håller frågan "hitta nästa körbara jobb" snabb även när tabellen växer.

Låsning och säkert anspråk på jobb

Målet är enkelt: många workers kan köras, men bara en ska kunna ta ett specifikt jobb. Om två workers processar samma rad får du dubbla mejl, dubbla avgifter eller rörig data.

Ett säkert tillvägagångssätt är att behandla ett jobbanspråk som ett "leasingavtal". Workern markerar jobbet som låst för ett kort fönster. Om workern kraschar går leasetiden ut och en annan worker kan plocka upp det. Det är vad locked_until är till för.

Använd en lease så krascher inte blockerar arbete för evigt

Utan lease kan en worker låsa ett jobb och aldrig låsa upp det (processen dödad, servern rebootad, deploy misslyckad). Med locked_until blir jobbet tillgängligt igen när tiden passerat.

En typisk regel är: ett jobb kan göras anspråk på när locked_until är NULL eller locked_until <= now().

Gör anspråk med en atomär uppdatering

Den viktiga detaljen är att göra anspråk i en enda sats (eller en transaktion). Du vill att databasen ska vara domaren.

Här är ett vanligt PostgreSQL-mönster: plocka ett förfallet jobb, lås det och returnera det till workern. (Detta exempel använder en enda jobs-tabell; samma idé gäller om du gör anspråk från job_runs.)

WITH next_job AS (
  SELECT id
  FROM jobs
  WHERE status = 'queued'
    AND run_at <= now()
    AND (locked_until IS NULL OR locked_until <= now())
  ORDER BY run_at ASC
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
UPDATE jobs j
SET status = 'running',
    locked_until = now() + interval '2 minutes',
    locked_by = $1,
    attempts = attempts + 1,
    updated_at = now()
FROM next_job
WHERE j.id = next_job.id
RETURNING j.*;

Varför det fungerar:

• FOR UPDATE SKIP LOCKED låter flera workers tävla utan att blockera varandra.
• Leasen sätts vid anspråkstidpunkten, så andra workers ignorerar den tills den går ut.
• RETURNING ger raden till den worker som vann racet.

Hur lång ska leasetiden vara, och hur förnyar du den?

Sätt leasetiden längre än en normal körning, men kort nog så en krasch återhämtar sig snabbt. Om de flesta jobb slutförs på 10 sekunder är en 2 minuters lease mer än tillräckligt.

För långa uppgifter, förnya leaset medan du arbetar (en heartbeat). Ett enkelt tillvägagångssätt: förläng locked_until var 30:e sekund om du fortfarande äger jobbet.

• Lease-längd: 5x till 20x din typiska jobbtid
• Heartbeat-intervall: 1/4 till 1/2 av leaset
• Förnyelseuppdateringen ska inkludera WHERE id = $job_id AND locked_by = $worker_id

Den sista villkorssatsen är viktig. Den förhindrar att en worker förlänger en lease på ett jobb den inte längre äger.

Retries och backoff som beter sig förutsägbart

Retries är där detta mönster antingen känns lugnt eller blir till ett bullrigt kaos. Målet är enkelt: när ett jobb misslyckas, försök igen senare på ett sätt du kan förklara, mäta och stoppa.

Börja med att göra jobbstatus explicit och ändlig: queued, running, succeeded, failed, dead. I praktiken använder de flesta team failed för att betyda "misslyckades men kommer att retry:as" och dead för att betyda "misslyckades och vi gav upp". Den distinktionen förhindrar oändliga loopar.

Försöksräkning är det andra skyddsräcket. Spara attempts (hur många gånger du försökt) och max_attempts (hur många gånger du tillåter). När en worker fångar ett fel ska den:

• öka attempts
• sätta state till failed om attempts < max_attempts, annars dead
• beräkna run_at för nästa försök (endast för failed)

Backoff är bara regeln som bestämmer nästa run_at. Välj en, dokumentera den och håll den konsekvent:

• Fast fördröjning: vänta alltid 1 minut
• Exponentiell: 1m, 2m, 4m, 8m
• Exponentiell med tak: exponentiell men aldrig mer än t.ex. 30m
• Lägg till jitter: randomisera lite så jobb inte alla retry:ar exakt samtidigt

Jitter är viktigt när en beroendetjänst går ner och kommer upp igen. Utan det kan hundratals jobb retry:a samtidigt och misslyckas igen.

Spara tillräckligt med felinformation för att göra fel synliga och felsökningsbara. Du behöver inte ett fullständigt loggsystem, men du behöver grunderna:

• last_error (kort meddelande, säkert att visa i ett admin-gränssnitt)
• error_code eller error_type (hjälper gruppering)
• failed_at och next_run_at
• valfritt last_stack (endast om du kan kontrollera storleken)

En konkret regel som fungerar bra: markera jobb som dead efter 10 försök, och backoff exponentiellt med jitter. Det håller övergående fel retry:ande, men stoppar trasiga jobb från att elda upp CPU för evigt.

Idempotens: förhindra dubbletter även om ett jobb upprepas

Idempotens betyder att ditt jobb kan köras två gånger och ändå ge samma slutresultat. I detta mönster är det viktigt eftersom samma rad kan plockas upp igen efter en krasch, timeout eller retry. Om ditt jobb är "skicka en faktura-mejl", är det inte ofarligt att köra det två gånger.

Ett praktiskt sätt att tänka: dela varje jobb i (1) göra arbetet och (2) applicera en effekt. Du vill att effekten ska hända en gång, även om arbetet försöks flera gånger.

Använd en idempotency-nyckel bunden till affärshändelsen

En idempotency-nyckel bör komma från vad jobbet representerar, inte från worker-försöket. Bra nycklar är stabila och lätta att förklara, som invoice_id, user_id + day eller report_name + report_date. Om två jobbförsök hänvisar till samma verkliga händelse bör de dela samma nyckel.

Exempel: "Generera daglig försäljningsrapport för 2026-01-14" kan använda sales_report:2026-01-14. "Charge invoice 812" kan använda invoice_charge:812.

Tvinga "bara en gång" med databaskonstraint

Det enklaste skyddet är att låta PostgreSQL avvisa dubbletter. Spara idempotency-nyckeln där den kan indexeras, och lägg sedan till en unik constraint.

-- Example: ensure one logical job/effect per business key
ALTER TABLE jobs
ADD COLUMN idempotency_key text;

CREATE UNIQUE INDEX jobs_idempotency_key_uniq
ON jobs (idempotency_key)
WHERE idempotency_key IS NOT NULL;

Detta förhindrar att två rader med samma nyckel existerar samtidigt. Om din design tillåter flera rader (för historik), sätt unikheten på en "effects"-tabell istället, som sent_emails(idempotency_key) eller payments(idempotency_key).

Vanliga sidoeffekter att skydda:

• Mejl: skapa en sent_emails-rad med en unik nyckel innan du skickar, eller registrera ett provider-message-id när det väl är skickat.
• Webhooks: spara delivered_webhooks(event_id) och hoppa över om det redan finns.
• Betalningar: använd alltid betalproviderens idempotency-funktion plus din egen databasunika nyckel.
• Filskrivningar: skriv till ett tillfälligt namn och byt sedan namn, eller spara en file_generated-post nycklad på (type, date).

Om du bygger på en Postgres-baserad stack (t.ex. Go + PostgreSQL) är dessa unikhetskontroller snabba och lätta att hålla nära datan. Nyckelidén är enkel: retries är normala, dubbletter är undantag.

Steg-för-steg: bygga en minimal worker och scheduler

Välj en tråkig runtime och håll dig till den. Poängen med cron + databas-mönstret är färre rörliga delar, så en liten Go-, Node- eller Python-process som pratar med PostgreSQL räcker oftast.

Bygg det i fem små steg

1. Skapa tabellerna och indexen. Lägg till en jobs-tabell (plus eventuella uppslags-tabeller senare), indexera run_at och lägg till ett index som hjälper din worker att hitta tillgängliga jobb snabbt (t.ex. på (status, run_at)).

2. Skriv en liten enqueue-funktion. Din app ska infoga en rad med run_at satt till "now" eller en framtida tid. Håll payloaden liten och förutsägbar (ID:n och en job-typ, inte stora blobbar).

INSERT INTO jobs (type, payload, status, run_at, attempts, max_attempts)
VALUES ($1, $2::jsonb, 'queued', $3, 0, 10);

3. Implementera claim-loopen. Kör den i en transaktion. Välj några förfallna jobb, lås dem så andra workers hoppar över dem, och markera dem som running i samma transaktion.

WITH picked AS (
  SELECT id
  FROM jobs
  WHERE status = 'queued' AND run_at <= now()
  ORDER BY run_at
  FOR UPDATE SKIP LOCKED
  LIMIT 10
)
UPDATE jobs
SET status = 'running', started_at = now()
WHERE id IN (SELECT id FROM picked)
RETURNING *;

4. Processa och finalisera. För varje påstått jobb, gör arbetet och uppdatera sedan till done med finished_at. Om det misslyckas, registrera ett felmeddelande och flytta tillbaka till queued med en ny run_at (backoff). Håll finaliseringsuppdateringarna små och kör dem alltid, även om din process stängs ner.

5. Lägg till retry-regler du kan förklara. Använd en enkel formel som run_at = now() + (attempts^2) * interval '10 seconds', och stoppa efter max_attempts genom att sätta status = 'dead'.

Lägg till grundläggande synlighet

Du behöver inte en full dashboard dag ett, men du behöver tillräckligt för att märka problem.

• Logga en rad per jobb: claimed, succeeded, failed, retried, dead.
• Skapa en enkel admin-fråga eller vy för "dead jobs" och "gamla running jobs".
• Sätt alert på räkningar (t.ex. fler än N dead jobs det senaste timmen).

Om du redan kör en Go + PostgreSQL-stack mappar detta rent till en enda worker-binary plus cron.

Ett realistiskt exempel du kan kopiera

Föreställ dig en liten SaaS-app med två schemalagda jobb:

• En nattlig rensning som tar bort utgångna sessioner och gamla temporära filer.
• Ett veckovis "din aktivitetsrapport"-mejl som skickas till varje användare varje måndagsmorgon.

Håll det enkelt: en PostgreSQL-tabell för jobb, och en worker som kör varje minut (triggad av cron). Workern gör anspråk på förfallna jobb, kör dem och registrerar succé eller fel.

Vad som enqueues och när

Du kan enqueua jobb från några platser:

• Dagligen kl 02:00: enqueuea ett cleanup_nightly-jobb för "idag".
• Vid signup: enqueuea ett send_weekly_report-jobb för användarens nästa måndag.
• Efter en händelse (som "user clicked Export report"): enqueuea ett send_weekly_report-jobb som körs omedelbart för ett specifikt datumintervall.

Payloaden är bara det minsta workern behöver. Håll den liten så den är lätt att retry:a.

{
  "type": "send_weekly_report",
  "payload": {
    "user_id": 12345,
    "date_range": {
      "from": "2026-01-01",
      "to": "2026-01-07"
    }
  }
}

Hur idempotens förhindrar dubbelsändningar

En worker kan krascha i värsta ögonblicket: precis efter att den skickat mejlet men innan den markerat jobbet som "done". När den startar om kan den plocka samma jobb igen.

För att stoppa dubbelsändningar, ge arbetet en naturlig dedupe-nyckel och spara den där databasen kan tvinga den. För veckorapporter är en bra nyckel (user_id, week_start_date). Innan du skickar registrerar workern "jag ska precis skicka rapport X". Om den posten redan finns hoppar den över sändningen.

Detta kan vara så enkelt som en sent_reports-tabell med en unik constraint på (user_id, week_start_date), eller en unik idempotency_key på jobbet självt.

Hur ett fel ser ut (och hur det återhämtar sig)

Säg att din e-postleverantör tajmar ut. Jobbet misslyckas, så workern:

• ökar attempts
• sparar felmeddelandet för felsökning
• schemalägger nästa försök med backoff (t.ex. +1 min, +5 min, +30 min, +2 timmar)

Om det fortsätter att misslyckas förbi din gräns (som 10 försök), markera det som "dead" och sluta retry:a. Jobbet lyckas antingen en gång, eller så retry:as det enligt ett tydligt schema, och idempotens gör retry säkert.

Vanliga misstag och fallgropar

Cron + databas-mönstret är enkelt, men små misstag kan göra det till dubbletter, fastnade jobb eller överraskande belastning. De flesta problem dyker upp efter den första kraschen, deployen eller trafikspiken.

Misstag som orsakar dubbletter eller fastnade jobb

De flesta incidenter kommer från några fällor:

• Köra samma jobb från flera cron-poster utan en lease. Om två servrar tickar samma minut kan båda göra anspråk på samma jobb om inte anspråkssteget är atomärt och sätter ett lås (eller lease) i samma databastransaktion.
• Hoppa över locked_until. Om en worker kraschar efter att ha gjort anspråk kan den raden förbli "in progress" för evigt. En lease-tidsstämpel låter en annan worker säkert plocka upp den senare.
• Retry:a omedelbart vid fel. När ett API ligger nere skapar omedelbara retries spikar, använder upp rate-limits och fortsätter att misslyckas i en tight loop. Schemalägg alltid nästa försök i framtiden.
• Behandla "at least once" som "exactly once". Ett jobb kan köras två gånger (timeouts, worker-restarts, nätverksproblem). Om att köra två gånger är skadligt, gör sidoeffekterna säkra att upprepa.
• Spara stora payloads i jobbraden. Stora JSON-blobbar gör tabellen tjock, saktar ner index och gör låsning tyngre. Spara en referens (som user_id, invoice_id eller en filnyckel) och hämta resten när du kör.

Exempel: du skickar ett veckovis faktura-mejl. Om workern tajmar ut efter att ha skickat men före att markera jobbet som klart kan samma jobb retry:as och skicka ett duplicerat mejl. Det är normalt för detta mönster om du inte lägger till ett skydd (t.ex. registrera en unik "email sent"-händelse nycklad på invoice id).

Mindre uppenbara fallgropar

Undvik att blanda schemaläggning och exekvering i samma långlivade transaktion. Om du håller en transaktion öppen medan du gör nätverksanrop behåller du lås längre än nödvändigt och blockerar andra workers.

Se upp för klockskillnader mellan maskiner. Använd databastid (NOW() i PostgreSQL) som sanningskälla för run_at och locked_until, inte applikationsserverns klocka.

Sätt en tydlig maxkörtid. Om ett jobb kan ta 30 minuter, gör leaset längre än det och förnya den vid behov. Annars kan en annan worker plocka upp jobbet mitt i körningen.

Håll din jobs-tabell frisk. Om slutförda jobb staplas på för evigt blir frågor långsamma och låskontentionen ökar. Välj en enkel retention-regel (arkivera eller radera gamla rader) innan tabellen blir gigantisk.

Snabb checklista och nästa steg

Snabb checklista

Innan du skickar detta mönster, kontrollera grunderna. Ett litet utelämnande här brukar bli fastnade jobb, överraskande dubbletter eller en worker som hamrar databasen.

• Din jobs-tabell har det väsentliga: run_at, status, attempts, locked_until och max_attempts (plus last_error eller liknande så du kan se vad som hände).
• Varje jobb kan säkert köras två gånger utan skada. Om du är osäker, lägg till en idempotency-nyckel eller en unikhetsregel runt sidoeffekten (t.ex. en faktura per invoice_id).
• Det finns en tydlig plats för att observera fel och bestämma åtgärd: visa failed jobs, köra om ett jobb eller markera det som dead när det ska sluta retry:as.
• Din lease (lås) timeout är rimlig för arbetet. Den ska vara lång nog för normala körningar, men kort nog så krascher inte blockerar framsteg i timmar.
• Retry-backoff är förutsägbar. Den ska bromsa upp upprepade fel och den ska stoppa efter max_attempts.

Om dessa är sanna är cron + databas-mönstret vanligtvis stabilt nog för verklig belastning.

Nästa steg

När checklistan ser bra ut, fokusera på drift:

• Lägg till två små admin-åtgärder: "retry now" (sätt run_at = now() och rensa låset) och "cancel" (flytta till ett terminalt status). Dessa sparar tid vid incidenter.
• Låt workern logga en rad per jobb: job-typ, job-id, försöksnummer och resultat. Lägg en alert på växande felräkningar.
• Load-testa med en realistisk spike: många jobb schemalagda för samma minut. Om anspråks-steget blir långsamt, lägg till rätt index (ofta på status, run_at).

Om du vill bygga detta snabbt kan Koder.ai (koder.ai) hjälpa dig ta dig från schema till en deployad Go + PostgreSQL-app med mindre manuell koppling, medan du fokuserar på låsning, retries och idempotens-regler.

Om du senare växer ur denna setup kommer du ändå ha lärt dig jobblivscykeln tydligt, och samma idéer mappar väl till ett fullständigt kö-system.