Que sont LISTEN et NOTIFY ?

Question

Accepted Answer

**`LISTEN`** et **`NOTIFY`** fournissent un système de messagerie **publish/subscribe** intégré dans PostgreSQL — une session peut envoyer une notification sur un canal, et d'autres sessions écoutant ce canal la reçoivent instantanément. C'est une façon légère de pousser des événements en temps réel depuis la base de données sans polling.

## Le mécanisme de base

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN s'abonne à un canal ; NOTIFY publie sur lui (avec une charge utile textuelle optionnelle). Les auditeurs sont notifiés de manière asynchrone — aucun polling nécessaire.

## Déclencher NOTIFY automatiquement (un modèle courant)

```sql
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- notify with the new id
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
```

Combinier NOTIFY avec un **trigger** permet à la base de données de pousser automatiquement des événements lorsque les données changent (nouvelle commande, mise à jour de statut) — les serveurs d'application écoutant sur le canal réagissent en temps réel.

## Comment les applications l'utilisent

```text
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
```

## Limitations à connaître

```text
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
  (no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
  proper broker (RabbitMQ, Kafka) or a queue table.
```

## Pourquoi c'est important

`LISTEN`/`NOTIFY` est une fonctionnalité PostgreSQL utile et un peu méconnue qui fournit un **système de messagerie pub/sub intégré**, précieuse pour ajouter une **réactivité en temps réel** aux applications sans polling.

La valeur fondamentale est de permettre à la base de données de **pousser des événements** aux sessions d'application à l'écoute instantanément lorsque quelque chose se produit (une nouvelle commande, un changement de statut) — généralement combiné avec des **triggers** afin que les modifications de données notifient automatiquement les auditeurs, auxquels les serveurs d'application réagissent (en poussant vers des websockets, en invalidant les caches, en déclenchant des tâches de fond).

C'est précieux car cela fournit un comportement événementiel en temps réel sans l'inefficacité du **polling** répété de la base de données pour vérifier les changements (un modèle courant et gaspilleur que LISTEN/NOTIFY remplace élégamment).

Comprendre le mécanisme (LISTEN pour s'abonner, NOTIFY pour publier, avec des triggers pour la notification automatique lors des modifications de données) et comment les applications l'utilisent (écouter les événements pour conduire des réactions en temps réel) est utile pour construire des applications réactives et événementielles en utilisant uniquement PostgreSQL.

Il est tout aussi important de connaître les **limitations** : les notifications ne sont **pas persistées** (perdues si personne n'écoute — aucune garantie de durabilité), ont de petites charges utiles, et ne se déclenchent qu'après commit — donc c'est adapté à la signalisation légère en temps réel, *pas* un remplacement pour un courtier de messages durable (RabbitMQ, Kafka) lorsque la fiabilité et la persistance sont importantes.

Puisque la réactivité en temps réel est un besoin courant et que LISTEN/NOTIFY offre un moyen intégré sans polling pour l'atteindre dans les cas légers, le comprendre — le mécanisme pub/sub, le modèle de trigger, et surtout ses limitations (quand il suffit par rapport à quand un vrai courtier est nécessaire) — est une connaissance PostgreSQL précieuse et pratiquement pertinente pour construire des applications événementielles, une fonctionnalité intégrée utile qui est souvent oubliée.