Telemetría de checkout que sobrevive al rollback: contadores fuera de la transacción

Un dashboard de checkout solo sirve si su telemetría aguanta el mismo fallo que dispara el rollback. La receta que plantea un artículo publicado en Dev.to: emitir un puñado de contadores y gauges fuera de la transacción de pago, colgar un identificador estable de intento en los logs estructurados y decidir si se revierte con una ventana estrecha de evidencia. Todo eso sobre una API de métricas alojada, sin desplegar Prometheus ni el resto del stack.

Estado de negocio y estado de diagnóstico, separados

El argumento de fondo es que la operación de pago manda sobre la corrección del negocio y la telemetría solo la observa. Si metes las señales dentro de la transacción, un rollback puede borrar la única prueba de que algo falló; si las dejas fuera, un rollback deshace el pedido mientras una métrica ansiosa sigue diciendo que el checkout fue bien. Ese desajuste, en fintech, es el que conviene evitar.

Las reglas que propone el texto: cada intento lleva un checkout_id aleatorio, y por las etiquetas no pasa nunca un número de tarjeta, un email, un teléfono, un OTP ni un token de autorización. Las dimensiones de baja cardinalidad (region, payment_rail) van en las métricas agregadas; el identificador por intento se queda en los logs, que es donde se correlaciona. El resultado final se registra cuando el commit o el rollback ya han terminado, no antes.

Para el panel bastan tres señales: checkout_attempts y checkout_failures como contadores, más un gauge tipo db_ping_ms o queue_depth. Un healthcheck_success describe el resultado de una sonda, pero no demuestra que un pago haya pasado. Esa frontera es la que impide que un cuadro verde se convierta en una afirmación financiera falsa.

Umbrales versionados junto al despliegue

El dashboard tiene que responder a una decisión, no exhibir cada número emitido. Se comparan fallos con intentos en una ventana corta, pero exigiendo una muestra mínima antes de tocar el tráfico: el autor pone como ejemplo 20 intentos y una tasa de fallo máxima del 5%. Un fallo en un único intento merece atención sin apagar automáticamente un rail de pago; diez fallos en una ventana poblada son otra cosa. El cálculo vive fuera del camino de escritura.

El código de ejemplo hace la consulta a la API de métricas con urllib, con cuatro intentos y un timeout de 10 segundos por petición, y respeta la cabecera Retry-After cuando llega un 429. El propio texto avisa de que esos límites son decisiones operativas del ejemplo, no características medidas del proveedor. Los errores se mapean a una taxonomía revisada (validation, database, payment_provider) y el detalle sensible se queda en el sistema que ya tiene los controles de acceso y retención adecuados.

El artículo usa Infrai como proveedor concreto: una API REST sin SDK, con una sola clave y una sola factura. De su instantánea de discovery, fechada el 26 de septiembre de 2026, dice que expone 295 rutas en 20 módulos, sin necesidad de clave, con esquemas de petición y respuesta y ejemplos ejecutables en 10 lenguajes. También reconoce que los filtros de metrics.query no están declarados públicamente, y por eso el ejemplo no inventa ninguno. La cifra es suya, no de un tercero.

Lo relevante para quien opera esto: las métricas alojadas no bastan para paging, trazas distribuidas ni para probar que una tarea de liquidación programada se ejecutó. Sirven para un panel de salud con contadores y gauges, no para sustituir la monitorización de infraestructura. Y si el equipo va a atar un despliegue a este contrato, lo sensato es validar la forma de la consulta contra discovery y una cuenta de prueba antes de darlo por fijo.