Cómo incident.io eliminó Pub/Sub como punto único de fallo

incident.io procesa cada día alrededor de 240 millones de mensajes a través de más de 800 temas de eventos, por lo que su bróker de mensajería se había convertido en un componente crítico. Hasta ahora la compañía dependía exclusivamente de Google Cloud Pub/Sub, un servicio con un SLA del 99,95 % que en la práctica funcionaba mejor, pero que constituía un punto único de fallo incompatible con su propio objetivo de disponibilidad del 99,99 % para clientes Enterprise de su producto On-call. Para resolver esa dependencia, el equipo introdujo un segundo bróker —NATS, un proyecto adoptado por la CNCF— y construyó un balanceador de carga dinámico entre ambos, con una configuración activo-activo que reparte los mensajes mediante un hash sobre el ID del mensaje (un ULID) y una tirada ponderada configurable. Si un bróker presenta una tasa de error persistente, el sistema deja de enviarle tráfico de forma automática, sin intervención manual. La base que permitió esta transición fue una abstracción interna llamada eventadapter, que aísla el código de producto del bróker subyacente y permite cambiar de implementación en tiempo de ejecución. El artículo describe el proceso, las decisiones de diseño y las restricciones que impuso la interfaz preexistente, y cierra con una prueba real: la semana pasada el equipo apagó Pub/Sub en producción sin que ningún cliente notara el cambio.