Cómo verificar un feed de precios para un bróker

Qué debe demostrar la verificación de un feed de precios

La verificación debe demostrar que el feed utiliza las fuentes y reglas previstas, produce precios válidos para los símbolos esperados, los entrega a la conexión del cliente y responde de forma predecible cuando falla una fuente o un endpoint.

Ninguna medición demuestra todo esto por sí sola. La disponibilidad del servidor no garantiza la validez de las cotizaciones. Una suma de comprobación de la configuración no demuestra que las fuentes coincidan. Una cotización en tiempo real no prueba que el feed de respaldo esté listo. Las comprobaciones se complementan.

Las capas de verificación

El cliente decide qué significa «aceptable» para sus instrumentos y su caso de uso. Las páginas públicas no establecen un único umbral universal para las diferencias de precio, la latencia o la inactividad.

Comience con símbolos representativos

Un conjunto de pruebas útil debe ser lo bastante pequeño para entenderlo y lo bastante amplio para revelar comportamientos diferentes:

• un símbolo líquido con una ruta de origen sencilla;
• un instrumento construido a partir de varias fuentes;
• un instrumento sintético o calculado si se utiliza;
• un símbolo con un cambio de política programado;
• un símbolo menos activo, en el que la ausencia de actualizaciones pueda ser normal; y
• un símbolo adecuado para un escenario de fallo controlado.

Para cada símbolo, registre las entradas esperadas, la regla de precios, la precisión, la política de spread, el comportamiento de protección y los destinos. Así, una diferencia se puede explicar en lugar de limitarse a aparecer en rojo.

Verifique la configuración antes de comparar precios

Los precios del feed principal y el de respaldo pueden diferir por motivos legítimos de tiempo, pero no deben utilizar sin avisar reglas previstas diferentes.

CoinPriceFeeds muestra una huella compacta de la configuración de precios cargada. Compruébela en ambos endpoints antes de interpretar una diferencia entre cotizaciones. Si las huellas de configuración no coinciden, resuelva primero esa diferencia. Si coinciden, la investigación puede centrarse en el estado de las fuentes, los tiempos o la entrega.

La huella de configuración representa el contenido de la regla más que el momento en que se cargó. Por lo tanto, dos servidores pueden confirmar la misma política prevista incluso cuando sus tiempos de recarga son diferentes.

Compare el comportamiento en tiempo real, no una sola instantánea

Una sola cotización coincidente aporta pocas pruebas. Observe un periodo representativo y registre:

• el bid y el ask finales;
• las diferencias de precio medio y spread;
• el número de actualizaciones o la tasa de actividad;
• los símbolos que se mueven en un endpoint, pero no en el otro;
• las salidas no válidas o cruzadas;
• última hora de actualización observada; y
• la huella de configuración.

El periodo de comparación debe incluir movimientos normales de los instrumentos elegidos. Un mercado tranquilo puede requerir otra ventana de prueba o una comprobación explícita de la señal de mantenimiento.

Pruebe un fallo controlado

Las pruebas con todas las fuentes operativas solo cubren el caso más sencillo. Una demo o prueba de aceptación debe incluir un fallo representativo y seguro, por ejemplo, que una entrada se declare no disponible o quede obsoleta.

El resultado esperado debe escribirse antes de la prueba:

1. la entrada que ha fallado deja de ser válida;
2. los resultados dependientes se recalculan a partir de fuentes alternativas válidas, se mantienen o se marcan como no disponibles según la política;
3. el motivo queda visible;
4. los símbolos no relacionados continúan donde sea posible;
5. la monitorización registra el evento; y
6. la recuperación requiere solo las acciones acordadas para esa condición.

No ejecute pruebas de fallos destructivas sobre el feed activo de un cliente sin un plan acordado de mantenimiento y reversión.

Verifique desde ambos lados

La monitorización del lado del servicio explica lo que el motor de precios considera que ha enviado. La observación del lado del cliente muestra qué datos han atravesado el perímetro de su red y su analizador.

Las pruebas de aceptación útiles combinan ambos lados:

• el estado que muestran la monitorización y el panel de CoinPriceFeeds;
• el bridge del cliente o los registros de la sesión FIX;
• un cliente de streaming de referencia cuando sea adecuado;
• Feed Checker para una inspección visual rápida;
• una comparación simultánea de los feeds principal y de respaldo; y
• un informe escrito que enumere los umbrales, las exclusiones y las diferencias pendientes.

El Feed Checker resulta útil para una inspección visual, mientras que la descripción de la monitorización explica señales operativas más amplias.

Registre el método con cada resultado

Una cifra citable sin contexto no constituye una prueba útil. El resultado de una verificación debe indicar:

• fecha, zona horaria y período de observación;
• punto de medición del lado del cliente o del lado del servicio;
• endpoints y conjunto de símbolos;
• huellas de configuración;
• umbrales seleccionados;
• condiciones de las fuentes o del mercado;
• exclusiones y limitaciones conocidas; y
• quién revisó el resultado.

Así se evita presentar una prueba breve de laboratorio, una medición de red regional o un periodo de mercado con una actividad inusual como una garantía universal del servicio.

Mantenga los detalles sensibles en privado

La metodología pública puede explicar qué se comprueba. Las credenciales reales, los nombres de host, las asignaciones de símbolos del cliente, las rutas de red, los destinos de las alertas, los umbrales de protección y los registros de incidentes deben permanecer dentro del alcance autorizado para el cliente.