LISTEN/NOTIFY es el mecanismo de publicación y suscripción nativo de Postgres, pero presenta un problema de escalabilidad: cada nuevo cliente que escucha un canal incrementa el costo de emitir una notificación, y a partir de unos miles de oyentes el rendimiento cae en órdenes de magnitud. El problema se agrava cuando se interpone un agrupador de conexiones, como Multigres, porque LISTEN es un estado ligado a la sesión y el agrupador, por diseño, impide que el cliente posea una sesión fija.
Multigres resuelve el dilema con una conexión de escucha compartida y persistente por cada agrupador, separada del conjunto de conexiones de consulta. Se adquiere solo cuando un cliente ejecuta su primer LISTEN y se reserva mientras haya suscriptores. Sobre esa única conexión física, el agrupador mantiene un conteo de referencias por canal: la primera suscripción dispara un LISTEN real en el backend, y la última cancelación dispara el UNLISTEN correspondiente, de modo que el backend tiene exactamente una suscripción por canal distinto, sin importar cuántos clientes lo escuchen.
La emisión de NOTIFY se trata como una consulta normal, enrutada deliberadamente a la misma instancia donde reside la conexión de escucha compartida, ya que Postgres no entrega notificaciones entre instancias. El envío al cliente se realiza en dos niveles: del agrupador al gateway mediante un flujo gRPC de larga duración, y del gateway al cliente mediante una cola por conexión con un escritor en segundo plano. Para reproducir el comportamiento de Postgres, Multigres respeta la naturaleza transaccional de LISTEN y UNLISTEN, aplica una política de mejor esfuerzo ante la saturación de búferes y vacía las notificaciones pendientes antes del ReadyForQuery para que el cliente nunca vea un estado de suscripción obsoleto.