Definir la plataforma antes de la tecnología
Una plataforma de trading puede ser una interfaz para clientes, una herramienta interna, una capa de datos de mercado, gestión de órdenes o una combinación. Cada caso exige disponibilidad, latencia, permisos y explicación de resultados diferentes. Antes de elegir tecnologías, defina usuarios, mercados, instrumentos, horizontes temporales y límite entre mostrar información y ejecutar acciones. De lo contrario se puede optimizar una parte equivocada del sistema.
El encargo debe describir el recorrido principal y sus excepciones: conexión perdida, precio atrasado, orden rechazada, ejecución parcial y fuentes que no coinciden. ¿Quién decide en cada caso y qué muestra la plataforma? El primer resultado arquitectónico es un mapa de responsables y estados, no la elección de un framework ni el diseño de un gráfico. Las restricciones legales y de licencia dependen del producto y los proveedores concretos.
Datos de mercado: origen, tiempo e integridad
Un precio no es un número aislado. Necesita fuente, identificación del instrumento, marca temporal, contexto de mercado e indicación de si el flujo sigue vigente. Si hay varios proveedores, se definen el orden de elección, las reglas ante discrepancias y el significado de los registros históricos. Un valor atrasado no debe parecer actual sin aviso. Comprobar la calidad de los datos forma parte del comportamiento del producto, no solo de una alarma técnica.
Un flujo puede contener huecos, duplicados o cambios de orden. El receptor debe detectar cuándo su vista local deja de ser fiable y saber cómo obtener un nuevo estado de referencia. FIX Trading Community describe snapshots y actualizaciones incrementales para datos de mercado; el método real de recuperación depende del feed y su contrato. Un piloto debería interrumpir deliberadamente la conexión y comprobar cómo se detecta la pérdida de coherencia y qué se muestra después.
Una orden no es un botón
Enviar una orden no equivale a ejecutarla. Según el entorno puede ser necesario distinguir preparación, validación, envío, aceptación por un tercero, rechazo, ejecución parcial, cancelación y resultado final. Cada estado afecta de forma diferente a los fondos disponibles, la información presentada y las acciones permitidas. La vista debe seguir siendo coherente cuando una respuesta llega tarde o un mensaje se entrega dos veces.
Cada orden necesita un identificador que vincule la acción del usuario, la decisión interna y los mensajes del socio. Un resultado desconocido no debe mostrarse como fracaso seguro ni repetirse sin verificación. Desarrollo, operaciones y producto deberían poder explicar en un mismo diagrama qué sucede con un timeout o una confirmación tardía. Las pruebas deben incluir combinaciones de mensajes que llegan en un orden diferente al recorrido ideal.
La latencia necesita contexto
Pedir baja latencia es demasiado impreciso. Hay que definir desde dónde y hasta dónde se mide: de un mensaje de mercado a la pantalla, de la confirmación del usuario al envío de la orden o de la respuesta del socio a un estado visible. En cada camino importan tiempo habitual, picos, valores extremos y respuesta a sobrecarga. Un solo número sin método de medición sirve más al marketing que al control de calidad.
Se empieza con marcas temporales y correlación de eventos en los límites relevantes. Entonces la optimización puede dirigirse al cuello de botella real: red, serialización, base de datos, cola, renderizado o servicio externo. A veces son más importantes un estado correcto y un aviso claro de retraso que reducir unos milisegundos la media. La arquitectura se elige según el producto, el volumen y el coste de equivocarse.
Seguridad, permisos e historial
Ver datos, crear una orden, cambiar un límite y hacer una corrección administrativa son capacidades distintas. Los permisos deben reflejar rol, cuenta, instrumento y acción. Un cambio relevante puede requerir otra aprobación. Sesiones, secretos y credenciales del socio tienen ciclos de vida separados. Los registros de diagnóstico no deben copiar datos sensibles sin control, aunque sí permitir reconstruir un incidente concreto.
El registro de auditoría debe responder qué información y acciones estaban disponibles en un momento dado y qué mensajes recibió el sistema. Si los datos de mercado se corrigen después, el historial debe distinguir lo mostrado entonces de lo que hoy se considera correcto. Retención y reporting dependen del contexto legal y contractual. El diseño técnico debe respaldar requisitos verificados en vez de declarar una certificación genérica en una página comercial.
Observación operativa y recuperación
Una plataforma necesita más que comprobar si responde el servidor HTTP. Importan antigüedad del feed, huecos de secuencia, tiempo de procesamiento de órdenes, estados desconocidos y diferencias entre registros internos y del socio. Cada alarma debe tener responsable y procedimiento utilizable bajo presión. Demasiadas señales sin prioridad pueden retrasar la respuesta. El funcionamiento degradado es una decisión de producto: desactivar algunas acciones puede ser más seguro que mostrar una certeza injustificada.
Recuperarse de una caída implica restablecer el estado de mercado, completar mensajes faltantes y verificar órdenes abiertas. Restaurar solo la base de datos quizá no refleje la realidad del proveedor externo. Para cada camino crítico se decide qué puede reproducirse, qué debe consultarse de nuevo y qué requiere a una persona. Un ejercicio de recuperación en pruebas suele revelar hipótesis invisibles en los tests funcionales habituales.
Primer piloto y preguntas decisivas
El primer piloto debe unir un recorrido pequeño pero completo: identificación del instrumento, recepción y presentación de datos, preparación de una orden, envío, confirmación y resultado rastreable. También debe simular una caída del feed y un estado de orden desconocido. Así se comprueban juntos los límites técnicos y de uso. Un gráfico con datos de ejemplo ayuda a visualizar, pero no demuestra por sí solo un flujo seguro de negociación. El piloto debe revelar qué partes dependen de interfaces reales del socio.
Antes de estimar el resto, obtenga documentación y acceso de prueba para datos y ejecución, responsables de licencias, roles, volumen previsto y tiempos de las rutas críticas. Registre reglas para datos incompletos o atrasados. Decida quién responde por datos de mercado, por las órdenes y por las reclamaciones. Esto permite delimitar un primer alcance productivo, mediciones útiles y un plan de publicación sin promesas ajenas al entorno real.
No confunda la interfaz del cliente con toda la plataforma. Un núcleo de ejecución adquirido, la capa de integración y una aplicación propia pueden tener responsables y ciclos de publicación distintos. Compare el control del estado de las órdenes, el acceso a pruebas, las licencias, la recuperación y los cambios futuros. Una interfaz cuidada no compensa la falta de eventos en el contrato del socio; reconstruir un componente de ejecución fiable puede añadir riesgo sin valor equivalente.
- ¿Qué mensaje es la fuente principal del precio, estado de orden y ejecución final?
- ¿Cómo sabe el usuario que los datos están atrasados o incompletos?
- ¿Qué ocurre si tras enviar una orden nunca llega respuesta del socio?
- ¿Cómo se procesan informes de ejecución duplicados o tardíos?
- ¿Puede reconstruirse lo que vio el usuario al decidir?
- ¿Quién aprueba cambios en reglas de negociación o límites?
- ¿Cómo se concilia el estado interno con el socio después de una caída?
- ¿Qué tiempos se miden y cuáles son de verdad importantes para el usuario?