Identifique origen y derecho de uso
La arquitectura empieza por el uso previsto: pantalla humana, cálculo interno, análisis histórico o redistribución. Un mismo precio puede tener condiciones contractuales diferentes en cada caso. Registre proveedor, mercado, tipo de flujo, instrumentos y formas permitidas de mostrar o conservar datos. Los ingenieros necesitan esos límites antes de diseñar cachés y exportaciones. De lo contrario pueden construir una función que la licencia no permite.
Separe el derecho contractual de la capacidad técnica para descargar información. Conectarse correctamente a una API no concede permiso para distribuir su salida a otros clientes. Para datos históricos defina retención y correcciones. Los derechos dependen del contrato y mercado concretos, así que esta página no ofrece conclusiones generales de licencia. Un inventario claro permite a responsables comerciales y jurídicos verificar la opción a tiempo.
El tiempo es más de una cifra
Un evento puede tener hora de origen en el mercado, de envío por el proveedor, de recepción en la infraestructura y de procesamiento en la aplicación. Mezclarlas en un campo impide saber si el retraso nació en fuente, red o sistema propio. La documentación de Databento diferencia marcas de evento, envío y recepción, y advierte que la precisión de la marca original varía. El principio vale también para otros proveedores.
Conserve la marca original al normalizar y añada su propia observación. Documente zona horaria, precisión y valores ausentes. Para comparar mercados hay que saber si dos fuentes miden el mismo instante. Un orden incorrecto puede crear una secuencia histórica falsa. Una interfaz en vivo debe mostrar la antigüedad de la información. La calidad temporal es una propiedad comercial de los datos, no solo el tipo de una columna.
Normalice sin perder significado
Los proveedores usan identificadores de instrumentos, tamaños, unidades de precio y tipos de eventos distintos. Una capa de normalización ayuda a trabajar con un modelo común, pero no debe ocultar diferencias que cambian el resultado. Mantenga origen y regla de conversión por campo. Algunos atributos deben seguir siendo específicos del mercado. Una estructura universal con cientos de campos vacíos puede ser peor que tipos claros y versionados.
Prepare muestras de actualizaciones normales, valores ausentes, correcciones históricas y cambios en la definición del instrumento. Una nueva versión del mapeo no debe cambiar silenciosamente el significado de datos guardados. Conserve cuando sea posible referencia al mensaje original para explicar un cálculo discutido. Si cambia el esquema del proveedor, hace falta una alerta y un procedimiento, no otra columna vacía.
Instantáneas, incrementos y huecos
Un flujo en vivo puede comenzar con una instantánea completa y seguir con cambios parciales. FIX Trading Community describe mensajes de actualización completa e incremental. La aplicación debe reconstruir un estado coherente y saber qué hacer si falta un cambio o llega fuera de orden. Sin esa lógica, una pantalla puede parecer activa y mostrar un libro o precio incorrecto.
Observe números de secuencia, antigüedad del último mensaje y estado de conexión según el protocolo. Al detectar un hueco, marque el resultado como no fiable, obtenga otra instantánea y reanude según el proveedor. No continúe cálculos silenciosamente con un estado incompleto. La reproducción histórica debe aplicar la misma definición de orden que el flujo en vivo, o piloto y producción pueden discrepar.
Distribuya y almacene según el uso
Una aplicación necesita cada cambio; otra solo el último precio o un resumen por intervalos. No imponga el flujo más exigente a todos. Defina productos de datos con antigüedad, integridad y método de cálculo. La caché necesita periodo de validez y conducta durante una caída de la fuente. Un valor antiguo debe marcarse como tal y no parecer información en tiempo real.
La conservación depende de volumen, consultas y licencia. En análisis histórico, separe entrada original de agregados derivados para poder reparar un cálculo incorrecto. En pantallas en vivo mida clientes simultáneos y capacidad de recuperar retrasos. Compare compresión y procesamiento por lotes con la latencia necesaria; la mínima latencia técnica no siempre es el objetivo comercial.
La vigilancia de calidad forma parte del producto
Defina frecuencia esperada y horario relevante para cada flujo. Retraso, caída, mensajes duplicados y saltos extraños son problemas diferentes y exigen respuestas distintas. Un panel debe mostrar antigüedad del último mensaje válido, huecos, velocidad de procesamiento y estado de consumidores importantes. Cada alerta necesita responsable. Sin alguien que actúe, el gráfico es decoración mientras otras personas pueden decidir con información vieja.
Compruebe también la relación entre fuentes. Dos flujos pueden usar métodos distintos, así que una diferencia no demuestra por sí sola un fallo. Al corregir un valor, registre su procedencia y si debe recalcularse el histórico. Es importante explicar el incidente: inicio, personas afectadas, salidas que deben revisarse y forma de evitar que se repita.
Un piloto comprueba el riesgo decisivo
Haga un piloto con un proveedor, pocos instrumentos y un consumidor definido. Incluya actividad normal, periodos sin mensajes, reinicio de conexión y datos corregidos. Compare el mensaje original con lo que muestra la aplicación. Si el producto necesita varios mercados, pruebe pronto sus diferencias de marcas temporales e identificadores. Una prueba de carga con cifras aleatorias no demuestra por sí sola el tratamiento correcto de datos reales.
Esta página no afirma que EXCOIN tenga acceso a flujos de pago, licencia de bolsa ni resultados de proyectos con clientes. El diseño real necesita condiciones del proveedor y uso exacto. Primeros resultados útiles son contrato de datos, definición de actualidad, prueba de recuperación tras huecos y medidas de calidad. Indican si basta una integración sencilla o conviene una plataforma separada para varios consumidores.
Incluya en el piloto un cambio de proveedor o del formato del mensaje. Compruebe quién recibe la alerta, cómo se detiene la publicación de valores poco fiables y cuándo vuelve el flujo normal. Los consumidores tienen distinta tolerancia a una caída: un análisis interno puede esperar, una pantalla en vivo debe mostrar la antigüedad de los datos inmediatamente. Anote la regla de cada uno. Tras un incidente, reproduzca mensajes conservados y compare si el cálculo corregido produce el resultado esperado. Sin esa reproducción, la reparación sigue siendo una suposición.