Pruebas de carga de una plataforma de trading: lista para la semana del lanzamiento

Una subestimación de 2x del flujo máximo de órdenes puede hacer que un broker pierda la ventana de lanzamiento: las colas crecen, las confirmaciones de órdenes no cumplen los objetivos y el personal de operaciones empieza a conciliar el estado manualmente. Las pruebas de carga antes del lanzamiento permiten al equipo averiguar si la plataforma de trading puede absorber la carga prevista, no solo si un único endpoint de API responde con rapidez.

El trabajo es práctico, pero necesita límites claros. Esta lista está diseñada para aplicarse esta semana, con un entorno similar al de producción, una carga de trabajo registrada y límites de aprobación acordados antes de la primera prueba. Abarca el recorrido desde la solicitud del cliente hasta el riesgo, la ejecución y la generación de informes, e incluye la recuperación en lugar de dejarla para un ejercicio posterior.

Defina primero la carga de trabajo y los límites

Empiece con la previsión del lanzamiento del producto y haga pruebas por encima de ella. Separe la actividad media prevista de los picos breves. Una plataforma que gestiona 500 solicitudes de órdenes por segundo de media puede tener problemas con un pico de 1,500 solicitudes si todas llegan a la vez a una cuenta, un símbolo o una partición de riesgo.

Utilice cifras de productos existentes cuando estén disponibles, pero incluya un margen razonable para el crecimiento inicial. Los rangos habituales de planificación son entre 1.5x y 3x el rendimiento máximo previsto y entre 2x y 5x el número esperado de sesiones simultáneas.

Modele la combinación completa de transacciones, no una sucesión de envíos de órdenes idénticas. Incluya inicios de sesión y renovaciones de sesión, suscripciones a datos de mercado, órdenes nuevas y modificadas, cancelaciones, ejecuciones, consultas de saldos y posiciones, y reconexiones tras una breve interrupción de red. Para un broker o una prop firm, el motor de riesgo puede ser el servicio que limite la capacidad, aunque el gateway y la conexión de ejecución o de casación parezcan funcionar correctamente. Incluya en la carga de trabajo las órdenes rechazadas y las comprobaciones de riesgo, ya que también consumen capacidad de computación y de base de datos.

Defina los límites de aprobación antes de las pruebas. Utilice objetivos de nivel de servicio que se ajusten al producto y al mercado, en lugar de escoger un umbral después de ver los resultados. Como punto de partida, puede incluir:

• Latencia de confirmación de órdenes en p50, p95 y p99, medida desde el envío del cliente hasta la respuesta que este recibe realmente.
• Rendimiento de órdenes y cancelaciones, con un recuento separado de solicitudes aceptadas, rechazadas, agotadas por tiempo de espera y duplicadas.
• Retraso en la entrega de datos de mercado y actualizaciones perdidas o fuera de secuencia, medidos en el límite de la aplicación.
• Latencia de las decisiones de riesgo, profundidad de las colas, uso de conexiones a la base de datos y retraso del broker de mensajes.
• Tiempo de recuperación tras el reinicio de un servicio, una pérdida de red o la ralentización de una dependencia, incluido el tiempo hasta que se concilian las posiciones y el estado de las órdenes.

Establezca un criterio de parada estricto para los defectos de integridad. Cualquier ejecución duplicada, orden aceptada perdida, posición incoherente o aceptación no autorizada de una orden supone el fracaso de la prueba, independientemente de la latencia media. Quienes siguen la cobertura de infraestructura de Trading Technology reconocerán la diferencia: las cifras de capacidad importan, pero solo junto con los controles y la integridad del estado.

Prepare un entorno de pruebas similar al de producción

Utilice las mismas versiones de software, configuración, tamaños de instancia, rutas de red y almacenes de datos previstos para el lanzamiento. Si el diseño de producción utiliza gateways separados por región, pruebe cada ruta. Un entorno más pequeño aún puede revelar cuellos de botella de la aplicación, pero no permite determinar la capacidad de producción mediante una simple multiplicación. Los bloqueos compartidos de bases de datos, las tasas de aciertos de la caché, los vecinos ruidosos y los límites de red no siempre escalan de forma lineal.

Utilice cuentas e instrumentos sintéticos con distribuciones realistas. Mil usuarios virtuales que envían órdenes a un único símbolo líquido sirven para probar un punto caliente, pero no representan un perfil de lanzamiento típico. Distribuya el tráfico entre los símbolos y tamaños de cuenta más comunes y añada después un pico concentrado para detectar particiones o estados de riesgo compartidos. Utilice un flujo de datos de mercado con precios cambiantes y tasas de actualización realistas; un conjunto de datos estático puede ocultar los costes de distribución a los sistemas posteriores y de serialización.

Incluya el generador de carga en el diseño de la prueba. Ejecútelo en un host o clúster independiente, confirme que dispone de capacidad de CPU y red sobrante y monitorícelo con el mismo cuidado que la plataforma. Si el generador se satura primero, el máximo registrado no representa el límite de la plataforma. Sincronice los relojes de clientes y servicios, y registre las marcas de tiempo en la creación de la solicitud, la recepción en el gateway, la decisión de riesgo, el envío al mercado y la respuesta al cliente. Así, el equipo podrá distinguir la latencia de la aplicación de la latencia de red y de ejecución externa.

Prepare un archivo o script de carga de trabajo repetible con una semilla fija. Registre el número de cuentas, el aumento progresivo de sesiones, la combinación de órdenes, los símbolos, las tasas de solicitudes y los fallos inyectados. Mantenga los datos de prueba aislados de las cuentas y rutas de mercado de producción. Para mercados externos, utilice un simulador certificado o un entorno de pruebas controlado, y especifique claramente los límites de las solicitudes salientes. La prueba nunca debe enviar tráfico sin control a un mercado activo.

Antes de la prueba, compruebe que los registros, el tracing y las métricas estén habilitados al nivel necesario para el diagnóstico, sin alterar accidentalmente el rendimiento por un exceso de registros de depuración. Conserve las muestras de latencia sin procesar, no solo los promedios de los paneles. Los promedios ocultan el comportamiento de cola, y una única cifra p99 también puede ocultar un pico breve pero perjudicial durante un aumento de carga o una conmutación por error.

Ejecute la prueba por etapas controladas

No empiece con la carga máxima. Una ejecución por etapas ayuda a distinguir los efectos del calentamiento de un límite real de capacidad y da tiempo al equipo para detenerse antes de que las colas resulten imposibles de recuperar.

Mantenga cada etapa el tiempo suficiente para detectar aumentos del uso de memoria, fugas de conexiones y persistencia diferida. Para la mayoría de las comprobaciones previas al lanzamiento, un periodo estable de 15 a 30 minutos por nivel de carga es un buen punto de partida; cuando se espere que el servicio tenga una carga elevada durante horas, se necesitan pruebas de duración más larga.

Siga este orden y registre la hora de inicio, la versión de la carga de trabajo y el resultado de cada paso:

1. Base: Ejecute una carga pequeña y representativa durante 10 a 15 minutos. Confirme que las marcas de tiempo, los contadores y el tracing coincidan, y registre el uso de recursos en reposo.
2. Aumento progresivo: Incremente las sesiones y las solicitudes por etapas, normalmente entre un 10 y un 20 por ciento cada pocos minutos. Vigile la profundidad de las colas y la latencia de cola, no solo la CPU.
3. Pico previsto: Mantenga el pico previsto para el lanzamiento el tiempo suficiente para alcanzar un estado estable. Compruebe todos los límites de aprobación y compare la respuesta visible para el cliente con los tiempos internos de los servicios.
4. Pico de carga: Pruebe el margen acordado, normalmente entre 1.5x y 3x el pico previsto. Mantenga una combinación de órdenes representativa y, después, ejecute por separado un pico concentrado en un símbolo o una cuenta.
5. Prueba de duración: Mantenga una carga elevada realista durante al menos 60 a 120 minutos si el tiempo lo permite. Haga un seguimiento de la memoria, las conexiones abiertas, el comportamiento de la caché, los pools de bases de datos y las tendencias de las colas.
6. Recuperación: Mientras continúa la carga, reinicie una instancia de un servicio no crítico o introduzca un retraso controlado en una dependencia. Verifique que el tráfico se desvíe según lo previsto y que el estado de las órdenes siga siendo coherente.
7. Reducción de carga: Reduzca la carga y confirme que las colas se vacían, el uso de recursos vuelve a acercarse al nivel de base y ninguna tarea de conciliación en segundo plano queda bloqueada.

Cambie una sola variable a la vez durante las pruebas de diagnóstico. Si una prueba combina una conmutación por error de la base de datos, un pico de inicios de sesión y una desconexión del mercado, el resultado puede mostrar un fallo sin identificar su causa. Una vez superadas las pruebas aisladas, ejecute un escenario combinado que se parezca al riesgo de lanzamiento que más preocupa al equipo de operaciones.

No dé una prueba por satisfactoria mientras haya órdenes aceptadas esperando en una cola que no se esté midiendo.

Analice las cifras y localice el cuello de botella

Utilice la tabla como referencia de rangos iniciales habituales, no como compromisos universales de nivel de servicio. El tipo de producto, la conectividad con el mercado, la jurisdicción, las reglas de las órdenes y la aplicación del cliente influyen en los límites adecuados. Antes del lanzamiento, el equipo debe sustituir estos rangos por sus propios objetivos aprobados.

Interprete las métricas en conjunto. Una CPU elevada en el gateway con un uso normal de la base de datos puede apuntar a la serialización, la autenticación o el registro por solicitud. Una CPU baja junto con un aumento de la antigüedad de las colas suele apuntar a una dependencia bloqueada, al agotamiento del pool de conexiones o a un pool de workers demasiado pequeño. Un aumento repentino de p99 con un p50 estable suele indicar contención, colas o un vecino ruidoso, no una ralentización de toda la plataforma.

Tracee una pequeña muestra de solicitudes lentas a través de los límites entre servicios. Busque llamadas repetidas a la base de datos, escrituras síncronas de auditoría, contención de bloqueos, consultas de riesgo lentas y ciclos de reintentos. Compruebe si los reintentos amplifican la demanda: si una llamada a un sistema posterior agota el tiempo de espera y todos los clientes reintentan de inmediato, el tráfico de reintentos puede superar la carga original. Añada reintentos limitados con jitter cuando corresponda y verifique que las claves de idempotencia impidan que un envío repetido cree una segunda orden.

En cada etapa, guarde un breve paquete de evidencias: la definición de la carga de trabajo, la versión del despliegue, capturas de métricas, percentiles de latencia, recuentos de errores, antigüedad de las colas y notas del operador. Incluya una lista de las diferencias conocidas respecto a producción. Una prueba sin una configuración reproducible es difícil de comparar después de un cambio de código o infraestructura.

Pruebe los fallos, la recuperación y el criterio de lanzamiento

La capacidad por sí sola no demuestra que todo esté listo para el lanzamiento. Defina un pequeño conjunto de fallos controlados que reflejen la arquitectura real y las consecuencias de perder cada dependencia. Empiece con una instancia de servicio y pase a un fallo de base de datos o de broker de mensajes solo si el entorno de pruebas está aislado y se conoce el procedimiento de recuperación. Nunca improvise pruebas destructivas en un entorno compartido.

Para cada fallo, compruebe tanto la respuesta técnica como el flujo de trabajo del operador. ¿La comprobación del estado retira la instancia fallida? ¿Los clientes reciben un tiempo de espera claro o un mensaje de éxito engañoso? ¿Se consultan o reproducen de forma segura las órdenes en curso? ¿Puede el equipo de operaciones identificar las cuentas afectadas y conciliarlas con el sistema de registro? Una conmutación por error que restablece el rendimiento, pero deja incierto el estado de las órdenes, no supera la prueba.

Antes de aprobar el lanzamiento, confirme lo siguiente con ingeniería, operaciones y el responsable del producto:

• Las cargas de trabajo acordadas para el pico y el aumento de carga se completaron sin defectos de integridad.
• La latencia, las tasas de error y la antigüedad de las colas se mantuvieron dentro de los límites fijados antes de las pruebas, o tienen un responsable asignado y una excepción documentada.
• El escalado automático, el desvío del tráfico y los límites de conexiones funcionaron según la configuración, incluidos sus periodos de enfriamiento.
• Las alertas de monitorización se activaron con tiempo suficiente para que un operador pudiera actuar, y el runbook identifica al responsable del servicio y la vía de escalado.
• Los criterios de reversión son explícitos. Algunos ejemplos son el incumplimiento sostenido de p99, el aumento de la antigüedad de las colas, un nivel elevado de rechazos de órdenes o cualquier discrepancia entre las posiciones y las órdenes aceptadas.
• Las evidencias de las pruebas y los defectos pendientes están adjuntos a la decisión de lanzamiento, con una fecha de repetición de la prueba para cada corrección importante.

Adapte el criterio de lanzamiento al producto. Un símbolo nuevo en una plataforma consolidada puede requerir una prueba específica de concentración de solicitudes en una clave y de datos de mercado.

Una nueva ruta de ejecución, un nuevo motor de riesgo o un nuevo modelo de cuentas justifican una reproducción más amplia de la carga y pruebas de fallos. Para más contexto sobre la infraestructura de los brokers y las operaciones de plataforma, consulte nuestra cobertura sobre tecnología de trading.

Reserve esta semana una revisión de 90 minutos de la carga de trabajo de lanzamiento y obtenga el archivo de reproducción, los límites de aprobación y el nombre del responsable de la reversión.

#infraestructura de prop firm #pruebas de conmutación por error #rendimiento de la plataforma de trading #pruebas de plataformas de broker #pruebas de carga del flujo de órdenes #capacidad del sistema de trading #pruebas de latencia #pruebas de estrés de datos de mercado