La plateforme

Événements & jobs

Les modules collaborent sans se connaître via deux mécanismes PostgreSQL : un bus d'événements (LISTEN/NOTIFY) et une file de jobs (SKIP LOCKED).

Événements #

Un module déclare dans son manifeste ce qu'il publishes et ce à quoi il est subscribed. Le core relaie via LISTEN/NOTIFY et journalise dans core.event_log. Exemples réels (calendar) :

publishes  = ["EventCreated", "EventUpdated", "EventDeleted"]
subscribed = ["UserDeleted", "ContactUpdated"]

Charge utile typique (JSON) :

{ "type": "EventCreated",
  "payload": { "event_id": "…", "user_id": "…", "module_id": "calendar" } }

Note

Réagissez par exemple à UserDeleted pour purger les données de l'utilisateur dans votre schéma — c'est ainsi qu'on garde la cohérence sans couplage direct entre modules.

File de jobs (SKIP LOCKED) #

Pour le travail asynchrone (emails, exports, nettoyage, webhooks), poussez un job dans core.jobs ; des workers le réclament en concurrence sûre :

SELECT id FROM core.jobs
WHERE status = 'pending' AND run_after <= NOW()
FOR UPDATE SKIP LOCKED
LIMIT 10;

Champs clés : job_type, payload (JSONB), status (pending → running → done/failed), attempts/max_attempts, run_after (planification & retry).