Un stream, un lector: diseñando un standby que toma el relevo

El primer instinto para un pipeline de alertas fiable es correr dos lectores, y en este stream ese instinto sale mal: cada cuenta mantiene una conexión por stream, y una segunda conexión en vivo con la misma clave cierra la primera, como documenta la guía de configuración SSE, verificado el 2026-10-06. Dos lectores no doblan tu fiabilidad; te dan una pelea por el socket. El diseño que funciona es un primario y un standby que toma el relevo.

Primario y standby, no primario y rival

La forma es activo-pasivo. Un proceso sostiene el stream y trabaja. El standby corre en caliente: mismo código, misma configuración, ninguna conexión. Vigila el heartbeat del primario, y cuando el heartbeat se detiene por más que tu tolerancia, abre el stream y se convierte en el primario. El proceso viejo, si alguna vez despierta, encuentra su conexión cerrada por el relevo y sale.

Aquí es donde la regla de una conexión se vuelve una ventaja: el relevo no necesita protocolo de negociación, porque el propio stream expulsa al lector obsoleto.

El relevo necesita estado compartido

Un standby que toma el relevo en frío re-alerta todo lo que el primario ya trató. El almacén de deduplicación y la hora de la última alerta procesada deben vivir donde ambos procesos puedan leer, una pequeña base compartida o un montaje de archivo, escrita por cualquier proceso que sea dueño del stream en ese momento. La guía de deduplicación cubre un almacén que sobrevive a reinicios; la versión de failover del mismo consejo es que debe sobrevivir también a un cambio de dueño.

Los huecos durante el cambio siguen siendo huecos. La documentación no promete punto de reanudación, así que cualquier cosa que cayó mientras ningún proceso estaba conectado se pierde, y el camino de recuperación es la ventana de caídas recientes del endpoint REST de caídas, según la guía de configuración.

Qué tan rápido debe tomar el relevo el standby

El retraso del relevo es un trueque entre cambios falsos y alertas perdidas. Demasiado corto, y una pausa lenta de recolección de basura hace oscilar la propiedad de un lado a otro. Demasiado largo, y cada fallo real cuesta minutos de silencio. Empieza con tres heartbeats perdidos, y deja que los hábitos de la guía de configuración, el endpoint de salud y la comprobación de silencio, le digan al standby la diferencia entre un primario muerto y un mercado tranquilo.

Una conexión, un dueño, un standby en caliente. El stream impone el lector único; tu heartbeat decide quién es.