PostgreSQL LISTEN/NOTIFY: cuándo es suficiente para actualizaciones en vivo

¿Qué problema intenta resolver LISTEN/NOTIFY?

“Actualizaciones en vivo” en la UI de un producto suele significar que la pantalla cambia poco después de que ocurre algo, sin que el usuario tenga que refrescar. Un número se incrementa en un dashboard, aparece una insignia roja en una bandeja de entrada, un admin ve un pedido nuevo o aparece un toast que dice “Build finished” o “Payment failed”. La clave es el tiempo: se siente instantáneo, aunque en realidad sea un segundo o dos.

Muchos equipos empiezan con polling: el navegador pregunta al servidor “¿hay algo nuevo?” cada pocos segundos. El polling funciona, pero tiene dos inconvenientes comunes.

Primero, se siente lento porque los usuarios solo ven los cambios en la siguiente consulta programada.

Segundo, puede volverse caro porque haces comprobaciones repetidas incluso cuando no cambia nada. Multiplica eso por miles de usuarios y se convierte en ruido.

PostgreSQL LISTEN/NOTIFY existe para un caso más simple: “avísame cuando algo cambie”. En lugar de preguntar una y otra vez, tu app puede esperar y reaccionar cuando la base de datos envía una pequeña señal.

Encaja bien en UIs donde un empujón basta. Por ejemplo:

• Un mosaico del dashboard debería refrescarse porque cambiaron los totales
• El conteo de una insignia debe actualizarse porque llegó un nuevo ítem
• Aparece una alerta interna porque cambió el estado de un job

La compensación es simplicidad frente a garantías. LISTEN/NOTIFY es fácil de añadir porque ya está en Postgres, pero no es un sistema completo de mensajería. La notificación es una pista, no un registro duradero. Si un listener está desconectado, puede perder la señal.

Una forma práctica de usarlo: deja que NOTIFY despierte tu app y luego que tu app lea la verdad desde las tablas.

Cómo funciona PostgreSQL LISTEN/NOTIFY en términos sencillos

Piensa en PostgreSQL LISTEN/NOTIFY como un timbre sencillo integrado en tu base de datos. Tu app puede esperar a que suene el timbre, y otra parte del sistema puede tocarlo cuando algo cambia.

Una notificación tiene dos partes: un nombre de canal y un payload opcional. El canal es como una etiqueta de tema (por ejemplo, orders_changed). El payload es un mensaje de texto corto que adjuntas (por ejemplo, un id de pedido). PostgreSQL no impone ninguna estructura, así que los equipos suelen enviar pequeñas cadenas JSON.

¿Quién toca el timbre?

Una notificación puede ser desencadenada desde el código de la aplicación (tu servidor API ejecuta NOTIFY) o desde la propia base de datos usando un trigger (un trigger ejecuta NOTIFY después de un insert/update/delete).

• El código de la app es más fácil de seguir y probar.
• Los triggers ayudan cuando varios escritores tocan las mismas tablas y quieres un comportamiento consistente.

En el lado receptor, tu servidor abre una conexión a la base de datos y ejecuta LISTEN channel_name. Esa conexión se mantiene abierta. Cuando ocurre NOTIFY channel_name, 'payload', PostgreSQL empuja un mensaje a todas las conexiones que están escuchando ese canal. Tu app entonces reacciona (refrescar cache, obtener la fila cambiada, enviar un evento WebSocket al navegador, etc.).

Qué hace (y qué no hace) NOTIFY

NOTIFY se entiende mejor como una señal, no como un servicio de entrega:

• Dice a los listeners que “algo pasó” ahora mismo.
• No garantiza que every mensaje sea recibido (un listener desconectado lo pierde).
• No es una cola (los mensajes no se guardan para más tarde).
• El payload tiene límite de tamaño y debe ser pequeño.
• Debe apuntar a datos, no reemplazarlos (envía ids y luego consulta los detalles).

Usado así, PostgreSQL LISTEN/NOTIFY puede impulsar actualizaciones en vivo de la UI sin añadir infraestructura extra.

Cuándo LISTEN/NOTIFY es suficiente para actualizaciones en vivo

LISTEN/NOTIFY brilla cuando tu UI solo necesita un empujón de que algo cambió, no un stream completo de eventos. Piensa en “refresca este widget” o “hay un nuevo ítem” en lugar de “procesa cada clic en orden”.

Funciona mejor cuando la base de datos ya es tu fuente de verdad y quieres que la UI se mantenga en sincronía con ella. Un patrón común es: escribe la fila, envía una pequeña notificación que incluya un ID, y deja que la UI (o una API) obtenga el estado más reciente.

LISTEN/NOTIFY suele ser suficiente cuando la mayoría de estas condiciones se cumplen:

• El mensaje es una pequeña señal de “algo cambió”, no un payload completo.
• El volumen de eventos es bajo a moderado (las ráfagas están bien, el alto throughput sostenido no).
• Si un usuario pierde una notificación, la UI puede recuperarse recargando o con polling breve.
• Valoras la simplicidad más que las garantías de entrega perfectas (común en productos tempranos y herramientas internas).
• Tienes una base de datos primaria única y quieres menos piezas móviles.

Un ejemplo concreto: un dashboard interno muestra “tickets abiertos” y una insignia de “notas nuevas”. Cuando un agente añade una nota, tu backend la escribe en Postgres y NOTIFY ticket_changed con el ID del ticket. El navegador la recibe vía WebSocket y vuelve a pedir esa tarjeta de ticket. Sin infraestructura extra, la UI se siente en vivo.

Dónde LISTEN/NOTIFY empieza a fallar

LISTEN/NOTIFY puede funcionar muy bien al principio, pero tiene límites claros. Esos límites aparecen cuando tratas las notificaciones como un sistema de mensajería en lugar de un simple “toque en el hombro”.

La brecha más grande es la durabilidad. Un NOTIFY no es un job en cola. Si nadie está escuchando en ese momento, el mensaje se pierde. Incluso cuando un listener está conectado, un crash, deploy, problema de red o un reinicio de la BD puede cerrar la conexión. No vas a recuperar automáticamente las notificaciones “perdidas”.

Las desconexiones son especialmente dolorosas para funciones orientadas al usuario. Imagina un dashboard que muestra nuevos pedidos. Una pestaña del navegador se suspende, el WebSocket se reconecta y la UI parece “atascada” porque perdió algunos eventos. Puedes mitigar esto, pero la solución ya no es “solo LISTEN/NOTIFY”: reconstruyes el estado consultando la base de datos y usas NOTIFY solo como pista para refrescar.

El fan-out es otro problema común. Un evento puede despertar a cientos o miles de listeners (muchas instancias de app, muchos usuarios). Si usas un canal ruidoso como orders, todos los listeners se despiertan aunque solo a un usuario le importe. Eso puede crear picos de CPU y presión de conexiones en el peor momento.

El tamaño del payload y la frecuencia son las trampas finales. Los payloads de NOTIFY son pequeños, y eventos de alta frecuencia pueden acumularse más rápido de lo que los clientes pueden manejar.

Atento a estas señales:

• Necesitas entrega garantizada, reintentos u ordenamiento.
• Los clientes se reconectan a menudo y no pueden perder actualizaciones.
• Un canal despierta a muchos listeners que en su mayoría ignoran el evento.
• Envías payloads grandes o disparas eventos muchas veces por segundo.

En ese punto, mantiene NOTIFY como un “toque” y mueve la fiabilidad a una tabla o a un broker adecuado.

Paso a paso: un patrón simple que funciona

Un patrón fiable con LISTEN/NOTIFY es tratar NOTIFY como un empujón, no como la fuente de verdad. La fila en la base de datos es la verdad; la notificación dice a tu app cuándo mirar.

1) Escribe, confirma y luego notifica

Haz la escritura dentro de una transacción y solo envía la notificación después de que el cambio de datos esté comprometido. Si notificas demasiado pronto, los clientes pueden despertarse y no encontrar aún los datos.

Un setup común es un trigger que se dispara en INSERT/UPDATE y envía un mensaje pequeño.

NOTIFY dashboard_updates, '{\\\"type\\\":\\\"order_changed\\\",\\\"order_id\\\":123}'::text;

2) Elige nombres de canal simples y payloads tiny

El nombrado de canales funciona mejor cuando coincide con cómo la gente piensa sobre el sistema. Ejemplos: dashboard_updates, user_notifications, o por tenant como tenant_42_updates.

Mantén el payload pequeño. Pon identificadores y un tipo, no registros completos. Una forma útil por defecto es:

• type (qué pasó)
• id (qué cambió)
• opcional tenant_id o user_id

Esto reduce el ancho de banda y evita filtrar datos sensibles en logs de notificaciones.

3) Maneja reconexiones y vuelve a suscribirte en cada conexión

Las conexiones se caen. Planifícalo.

Al conectar, ejecuta LISTEN para todos los canales necesarios. Al desconectar, reconecta con un backoff corto. Al reconectar, ejecuta LISTEN de nuevo (las suscripciones no se mantienen). Tras reconectar, haz un refetch rápido de “cambios recientes” para cubrir eventos perdidos.

4) Actualiza la UI: refetch primero, parchea después

Para la mayoría de actualizaciones en vivo, volver a buscar es lo más seguro: el cliente recibe {type, id} y luego pide al servidor el estado más reciente.

El parche incremental puede ser más rápido, pero es más fácil que salga mal (eventos fuera de orden, fallos parciales). Un buen punto medio: refetch de pequeñas porciones (una fila de pedido, una tarjeta de ticket, un conteo) y deja agregados más pesados en un temporizador corto.

Patrones de escalado para dashboards y notificaciones

Cuando pasas de un dashboard administrativo a muchos usuarios observando los mismos números, las buenas prácticas importan más que SQL ingenioso. LISTEN/NOTIFY puede seguir funcionando, pero necesitas modelar cómo fluyen los eventos desde la BD hasta los navegadores.

Una base común es: cada instancia de app abre una conexión de larga duración que LISTEN, y luego empuja actualizaciones a los clientes conectados. Este “un listener por instancia” es simple y suele bastar si tienes pocas instancias y toleras reconexiones ocasionales.

Si tienes muchas instancias (o workers serverless), un servicio listener compartido puede ser más fácil. Un proceso pequeño escucha una vez y hace fan-out de actualizaciones al resto del stack. También te da un lugar para añadir batching, métricas y control de presión.

Para los navegadores, normalmente empujas con WebSockets (bidireccional, ideal para UIs interactivas) o Server-Sent Events (SSE) (unidireccional, más simple para dashboards). En cualquier caso, evita enviar “refrescar todo”. Envía señales compactas como “order 123 changed” para que la UI vuelva a pedir solo lo que necesita.

Para evitar que la UI haga re-render continuo, añade algunas protecciones:

• Debounce en ráfagas (por ejemplo, 100 a 500 ms) antes de empujar a clientes
• Coalescer duplicados (la misma fila cambiada 10 veces, envía 1 actualización)
• Usa “dirty flags” por widget en vez de refrescar la página completa

El diseño de canales también importa. En vez de un canal global, particiona por tenant, equipo o feature para que los clientes solo reciban eventos relevantes. Ejemplo: notify:tenant_42:billing y notify:tenant_42:ops.

Errores comunes y cómo evitarlos

LISTEN/NOTIFY parece simple, por eso los equipos lo lanzan rápido y luego se sorprenden en producción. La mayoría de problemas vienen de tratarlo como una cola de mensajes garantizada.

1) Tratar notificaciones como mensajes durables

Si tu app se reconecta (deploy, fallo de red, failover), cualquier NOTIFY enviado mientras estabas desconectado se pierde. La solución es hacer de la notificación una señal y volver a chequear la BD.

Un patrón práctico: almacena el evento real en una tabla (con id y created_at), luego al reconectar busca todo lo más nuevo que tu último id visto.

2) Sobrecargar el payload

Los payloads no son para grandes blobs JSON. Payloads grandes generan trabajo extra, más parsing y más posibilidades de alcanzar límites.

Usa payloads para pistas tiny como "order:123". Luego la app lee el estado más reciente de la base de datos.

3) Mezclar “señal” y “fetch de datos”

Un error común es diseñar la UI alrededor del contenido del payload, como si fuera la fuente de verdad. Eso hace que cambios de esquema y versiones de cliente sean dolorosos.

Mantén una separación clara: notifica que algo cambió y luego obtén los datos actuales con una consulta normal.

4) Triggers que se disparan demasiado seguido

Triggers que NOTIFY en cada cambio de fila pueden saturar tu sistema, especialmente en tablas con mucho tráfico.

Notifica solo en transiciones significativas (por ejemplo, cambios de estado). Si tienes updates muy ruidosos, agrupa cambios (un notify por transacción o por ventana de tiempo) o saca esas actualizaciones de la ruta de notificación.

5) Ignorar la presión en la UI

Aunque la BD pueda mandar notificaciones, la UI aún puede colapsar. Un dashboard que re-renderiza en cada evento puede congelarse.

Debounce en el cliente, colapsa ráfagas en un solo refresco y prefiere “invalidar y volver a pedir” sobre “aplicar cada delta”. Por ejemplo: el icono de notificaciones puede actualizarse instantáneamente, pero la lista desplegable puede refrescarse como máximo una vez cada pocos segundos.

Lista rápida: decide si LISTEN/NOTIFY encaja

LISTEN/NOTIFY es excelente cuando quieres una pequeña señal de “algo cambió” para que la app vuelva a pedir datos frescos. No es un sistema de mensajería completo.

Antes de construir la UI alrededor, responde estas preguntas:

• Si un listener está offline un minuto, ¿puede perder eventos sin romper nada? Si perderlos es inaceptable, necesitas entrega durable y replay.
• ¿Es suficiente “casi en tiempo real”? Si los usuarios toleran un breve retraso (o un refresco manual) durante deploys o fallos de red, normalmente LISTEN/NOTIFY sirve.
• ¿Cuál es tu pico de ráfagas? Unos pocos eventos por segundo, o picos ocasionales, son puntos óptimos. Volumen sostenido alto hace que los canales sean ruidosos y difíciles de manejar.
• ¿Cuántos consumidores escucharán a la vez? Una o pocas workers backend es fácil. Cientos o miles de clientes conectados suelen necesitar una capa de fan-out (tu servidor) en lugar de que todos escuchen directamente.
• ¿Necesitas orden estricto entre muchos tipos de eventos? Si tu dashboard depende de “A debe procesarse antes que B” entre múltiples streams, se complica rápido.

Una regla práctica: si puedes tratar a NOTIFY como un empujón (“ve y vuelve a leer la fila”) en lugar de como el payload en sí, estás en la zona segura.

Ejemplo: un dashboard admin muestra nuevos pedidos. Si se pierde una notificación, el siguiente polling o un refresco de página sigue mostrando el conteo correcto. Eso encaja bien. Pero si envías eventos tipo “cobrar esta tarjeta” o “enviar este paquete”, perder uno es un incidente real.

Ejemplo: dashboard en vivo más notificaciones de usuario

Imagina una pequeña app de ventas: un dashboard muestra los ingresos del día, total de pedidos y una lista de “órdenes recientes”. Al mismo tiempo, cada vendedor debe recibir una notificación rápida cuando una orden que le pertenece sea pagada o enviada.

Un enfoque simple es tratar a PostgreSQL como fuente de verdad y usar LISTEN/NOTIFY solo como un toque para decir que algo cambió.

Cuando se crea una orden o cambia su estado, tu backend hace dos cosas en una petición: escribe la fila (o la actualiza) y luego envía un NOTIFY con un payload tiny (a menudo solo el ID y el tipo de evento). La UI no depende del payload de NOTIFY para los datos completos.

Un flujo práctico sería:

• Escribir el cambio de orden en una transacción.
• Tras el commit, NOTIFY orders_events con {\\\"type\\\":\\\"status_changed\\\",\\\"order_id\\\":123}.
• Un listener backend recibe eventos y los empuja a navegadores conectados (WebSocket o SSE).
• El dashboard vuelve a pedir lo que necesita: la fila de orden por ID, y totales en un temporizador corto (por ejemplo cada 2 a 5 segundos) en vez de recalcular en cada evento.
• Las notificaciones de usuario son dirigidas: solo el vendedor suscrito a esa orden recibe el toast de “pagado” o “enviado”.

Esto mantiene NOTIFY ligero y limita consultas costosas.

Cuando el tráfico crece, aparecen grietas: picos de eventos pueden saturar un listener, las notificaciones se pierden al reconectar y necesitas entrega garantizada y replay. Ahí es cuando generalmente añades una capa más fiable (una tabla outbox más un worker, y luego un broker si hace falta) manteniendo Postgres como fuente de verdad.

Cuándo pasarte a un broker dedicado

LISTEN/NOTIFY es genial cuando necesitas una señal rápida de “algo cambió”. No está diseñado como un sistema de mensajería completo. Cuando empiezas a depender de eventos como fuente de verdad, es momento de añadir un broker.

Señales claras de que superaste LISTEN/NOTIFY

Si aparece alguna de estas, un broker te ahorrará problemas:

• Necesitas durabilidad: los eventos no deben perderse si la app se reinicia o la BD hace failover.
• Necesitas reintentos y manejo de dead-letter: si un consumidor falla, el mensaje debe reintentarse y seguirse.
• Necesitas grupos de consumidores: múltiples workers comparten la carga sin procesar doble.
• Necesitas auditoría y replay: “muéstrame todo lo ocurrido la última hora” o “reconstruye esta vista desde eventos”.
• Necesitas control de backpressure: los productores no deben abrumar a consumidores lentos.

LISTEN/NOTIFY no almacena mensajes para después. Es una señal push, no un log persistente. Perfecto para “refresca este widget”, arriesgado para “procesa facturación” o “envía un paquete”.

Qué añade un broker (en términos sencillos)

Un broker te da un modelo real de flujo de mensajes: colas (trabajo por hacer), topics (broadcast a muchos), retención (guardar mensajes minutos o días) y acknowledgments (un consumidor confirma el procesamiento). Eso te permite separar “la base de datos cambió” de “todo lo que debe pasar porque cambió”.

No hace falta elegir la herramienta más compleja. Opciones comunes: Redis (pub/sub o streams), NATS, RabbitMQ y Kafka. La elección depende de si necesitas colas de trabajo simples, fan-out a muchos servicios o la capacidad de reproducir historia.

Plan de migración gradual

Puedes moverte sin reescritura grande. Un patrón práctico es mantener NOTIFY como señal de despertado mientras el broker se convierte en la fuente de entrega.

Empieza escribiendo una fila de evento en una tabla dentro de la misma transacción que tu cambio de negocio, luego ten un worker que publique ese evento al broker. Durante la transición, NOTIFY puede seguir avisando a la capa de UI “revisa por nuevos eventos”, mientras los workers consumen del broker con reintentos y auditoría.

Así, los dashboards siguen rápidos y los flujos críticos dejan de depender de notificaciones de mejor esfuerzo.

Próximos pasos: lanza una versión pequeña y itera con seguridad

Elige una pantalla (un mosaico del dashboard, un contador de badge, un toast de “nueva notificación”) y conéctala de extremo a extremo. Con LISTEN/NOTIFY puedes obtener un resultado útil rápido, siempre que mantengas el alcance limitado y midas qué ocurre bajo tráfico real.

Empieza con el patrón fiable más simple: escribe la fila, confirma y luego emite una pequeña señal de que algo cambió. En la UI, reacciona a la señal pidiendo el estado más reciente (o la porción que necesitas). Esto mantiene los payloads pequeños y evita errores sutiles cuando los mensajes llegan fuera de orden.

Añade observabilidad básica desde el inicio. No necesitas herramientas sofisticadas, pero sí respuestas cuando el sistema se vuelve ruidoso:

• Registra reconexiones y suscripciones (con un motivo)
• Mide la tasa de notify y picos
• Mide la tasa de fetchs desencadenados por notificaciones
• Vigila síntomas de “actualización perdida” (usuarios que necesitan refrescar)

Mantén contratos sencillos y escritos. Decide nombres de canales, nombres de eventos y la forma de cualquier payload (aunque sea solo un ID). Un breve “catálogo de eventos” en tu repo evita deriva.

Si construyes rápido y quieres mantener la pila simple, una plataforma como Koder.ai (koder.ai) puede ayudarte a lanzar la primera versión con UI en React, backend en Go y PostgreSQL, y luego iterar según tus necesidades.