So funktioniert die Queue #
Die Web-App schreibt eine Zeile in die Tabelle jobs. Der Worker beansprucht Zeilen mit SELECT … FOR UPDATE SKIP LOCKED, führt den Handler aus und protokolliert das Ergebnis. Ein Postgres-LISTEN/NOTIFY-Trigger weckt den Worker in dem Moment, in dem ein Job eingefügt wird, sodass die Latenz bei Millisekunden liegt; ein Poll-Intervall fängt alles Verpasste ab.
Lebenszyklus: queued → running → succeeded | failed (Wiederholung mit Backoff) | cancelled. Jeder laufende Job sendet Heartbeats; ein Reaper reiht Jobs neu ein, deren Worker gestorben ist.
Job-Typen #
| Typ | Zweck |
|---|---|
mail.send | Transaktionale E-Mail. |
webhook.deliver | Ein Webhook-Zustellversuch. |
push.send | APNs-Push an registrierte Geräte. |
notify.digest | Täglicher Benachrichtigungs-Digest pro Nutzer. |
prune.jobs prune.invitations prune.notifications prune.webhook_deliveries | Aufbewahrung. |
Zeitpläne #
Der Scheduler liest alle paar Sekunden die Tabelle schedules, reiht pro fälliger Zeile einen Job ein und schiebt next_run_at um das Intervall der Zeile weiter. Er reiht nur ein; die Arbeit macht der Worker. Zeitpläne sind einfache Zeilen: per SQL pausieren, anpassen oder ergänzen, oder unter Admin → System → Zeitpläne umschalten.
Monitoring #
Admin → System → Jobs zeigt aktuelle Jobs mit Zustand, Kennzahlen zur Queue-Gesundheit und Aktionen zum Senden einer Test-E-Mail, Stoppen eines laufenden Jobs oder Wiederholen eines fehlgeschlagenen. Beide Go-Dienste loggen strukturierte Zeilen nach stdout.