Los webhooks antiguos deben drenar antes de cortar claves

Cortar claves mientras el webhook antiguo aún sostiene DLR in-flight deja caer la verdad de entrega en el aire. El comprador ve «sent» sin estado final; finanzas ve holds abiertos que nunca cierran; ops pierde el rastro que prueba el orden de failover. Primero drenar. Después cortar.

La rotación IOSOR trata el endpoint antiguo como una cola que debe callarse — no como un interruptor que se vuelve cuando la URL nueva responde a un smoke. Los reportes in-flight son parte del ciclo de vida del mensaje; huérfanos inventan una semana de filas fantasma.

Inventarie DLR in-flight en el endpoint antiguo

Exporte entregas abiertas y estados finales pendientes ligados a la URL webhook antigua. Etiquete cada fila con edad y message id. Ese inventario es el backlog de drenaje — no una vaga esperanza de que «los reintentos terminarán de algún modo».

Comparta el export con finanzas antes de que alguien programe un revoke de claves. Si el backlog es mayor que un turno silencioso, extienda la ventana de drenaje por escrito en lugar de cortar en una tormenta de DLR tardíos.

Drene hasta quiet, luego corte claves

Mantenga el endpoint antiguo Live solo para eventos de completion hasta que el inventario sea cero o un piso residual acordado. No revoque secretos de messaging o webhook mientras la lista de drenaje aún muestre llegadas frescas. Quiet significa sin nuevos finales en una ventana medida — no «se ve calmo en Slack».

Cuando quiet esté probado, revoque claves antiguas en la misma ventana de cambio que el flip a URL dueño único. Un revoke parcial que deja un secreto medio vivo es cómo llega DLR tardío a un camino muerto.

Mantenga el orden de failover honesto durante el drenaje

Mientras drena, no invente una segunda ruta Live que eluda la historia de backup ordenado. Failover sigue primary-then-backup; drenar no es permiso para fan-out. Documente qué ruta posee filas in-flight para que la semana de incidente no discuta qué tubería «debería haber» respondido.

Si primary falla a mitad del drenaje, siga la ruta de backup ordenado y re-inventarie — no corte claves como movimiento de pánico para «simplificar».

Re-pruebe el runway día-1 tras el corte

Tras cortar claves, ejecute las comprobaciones día-1 que deben estar verdes: heartbeat, proof de envío, finales webhook en el endpoint nuevo, cierre de hold en billetera. Solo entonces reabra volumen piloto. Una ruta antigua drenada más un runway rojo sigue siendo un lanzamiento bloqueado.

Exporte la primera hora silenciosa en la URL nueva para que ops muestre al comprador que el DLR no desapareció con el secreto antiguo.

Rutas operativas relacionadas

• Rotación de secretos de firma de webhooks sin pérdida de informes de entrega
• Pista del primer día: qué debe estar en verde
• ruta de backup ordenada sin doble débito

Comience con IOSOR

Exporte el backlog del endpoint antiguo, drene hasta quiet y luego revoque claves con la URL dueño único Live. Re-ejecute el runway día-1 en la ruta nueva y mantenga el orden de failover escrito para cualquier incidente a mitad de drenaje antes de subir volumen.

Conclusión IOSOR

Drene webhooks antiguos antes de cortar claves: el DLR in-flight es verdad que aún debe. Inventario, quiet, revoke y luego re-pruebe runway — nunca huérfane finales para que el calendario de cutover se vea más rápido.