Empresas de desarrollo de software de baja latencia: qué tipo necesitas y cómo poner a prueba una en tu propio sistema

Ninguna lista de empresas de desarrollo de software de baja latencia sirve a todos los compradores, porque el término abarca deadlines que pueden diferir en un factor de un millón. En el hardware de trading puede significar decenas o cientos de nanosegundos. En una app o una página web, una respuesta en torno a una décima de segundo ya le parece instantánea a quien la usa. Así que la primera pregunta es dónde cae tu propio deadline.

¿Qué significa «baja latencia» para nuestro sistema?

Para tu sistema, la baja latencia es un deadline medido entre dos puntos que puedes nombrar. Los deadlines se reparten en cuatro grandes rangos:

• Hardware de trading, en decenas o cientos de nanosegundos. STAC-T0, un benchmark desarrollado en consulta con empresas de trading del STAC Benchmark Council, mide lo rápido que el hardware y el software de red de un sistema convierten datos de mercado simulados en una orden simulada, sin ninguna lógica de trading de por medio. El resumen de STAC del 5 de noviembre de 2020 dice que el benchmark trata el sistema como una caja negra, «interactuando con él únicamente mediante paquetes de red, a los que pone marcas de tiempo por hardware», y que las marcas de tiempo por software pueden arrastrar un error considerable cuando se trata de decenas o cientos de nanosegundos. El stack bajo prueba (stack under test), como llama STAC al sistema que se mide, puede ser una tarjeta FPGA, que lleva un chip cuyos circuitos se programan para una sola tarea
• Centros de negociación, desde microsegundos hasta alrededor de un milisegundo. La norma de la UE sobre la precisión que deben tener los relojes de un centro de negociación vincula esa precisión al tiempo que tarda el sistema de negociación del centro en procesar una orden y devolver una confirmación. Desde el 2 de marzo de 2026, esa norma es el Reglamento Delegado (UE) 2025/1155 de la Comisión, que sustituyó a la norma anterior conocida como RTS 25 y llama a este tiempo latencia de gateway a gateway (gateway-to-gateway latency): «el tiempo medido desde el momento en que un gateway exterior del sistema del centro de negociación recibe un mensaje, este se envía a través del protocolo de envío de órdenes, lo procesa el matching engine y después se devuelve, hasta que se envía un acuse de recibo desde el gateway». Cuando eso lleva 1 milisegundo o menos, los relojes del centro no pueden desviarse más de 100 microsegundos del tiempo universal coordinado (UTC), y las marcas de tiempo deben tener una granularidad de 0.1 microsegundos o más fina
• Ad tech, desde decenas de milisegundos hasta un segundo. OpenRTB 2.6, el estándar de IAB Tech Lab para real-time bidding, permite a un exchange fijar un deadline en cada solicitud de puja, y el tiempo en tránsito por Internet cuenta dentro de ese deadline. La documentación para desarrolladores de Authorized Buyers de Google, actualizada por última vez el 17 de septiembre de 2026, dice que el deadline de respuesta «va de 80 a 1000 ms, según el formato y el tipo de subasta»
• Apps y páginas web que usan las personas, en torno a una décima de segundo. Jakob Nielsen escribió en 1993 que «0.1 segundos es aproximadamente el límite para que el usuario sienta que el sistema reacciona de forma instantánea». Para las páginas web, la guía web.dev de Google, actualizada por última vez en septiembre de 2025, considera buena la capacidad de respuesta cuando el Interaction to Next Paint (INP) es de 200 milisegundos o menos. El INP mide cuánto tarda una página en responder a clics, toques y pulsaciones de teclas

Un mismo producto puede tener partes en rangos distintos. Un trader lee los precios en una pantalla, mientras que la orden que envía ese trader puede tener que cumplir un deadline mucho más estricto en su camino hacia el centro de negociación. Anota cada deadline con los dos puntos entre los que se mide. El rango en el que cae cada uno te dice a qué tipo de empresa llamar.

¿Con qué empresas de desarrollo de software de baja latencia deberíamos hablar?

Este artículo no hace rankings de empresas. El tipo de empresa adecuado depende de tu rango y del trabajo que necesitas:

• Especialistas en hardware y redes, para deadlines que se cuentan en nanosegundos o en unos pocos microsegundos. Trabajan con tarjetas FPGA, tarjetas de red, switches y los enlaces con un exchange. Pregunta cuáles de sus cifras salen de marcas de tiempo tomadas por hardware en el cable de red y en los equipos de quién se ejecutaron las pruebas
• Empresas de ingeniería de tecnología de trading, para deadlines en microsegundos o milisegundos cuando el tiempo se pierde dentro de tu propio software o en el camino hacia tu bróker o centro de negociación. Escriben el software que envía órdenes, gestiona los datos de mercado, comprueba el riesgo de cada orden antes de que salga y, en un centro de negociación, casa las órdenes de compra y de venta. Pregunta qué sistemas construidos por ellas están hoy en producción y qué conexiones con brókers o centros de negociación escribieron
• Empresas de ingeniería de ad tech, cuando un exchange fija tu deadline solicitud a solicitud y tu factura de servidores crece con tu tráfico. Construyen bidders y ad exchanges. Pregunta qué bidder o exchange construido por ellas sigue en producción y si sus cifras de timeouts salen del recuento del exchange o del suyo propio
• Ingenieros de rendimiento independientes, cuando todavía no conoces la causa o cuando los cambios los van a hacer tus propios ingenieros. Suelen trabajar solos o en un grupo pequeño, miden un sistema en funcionamiento e informan de a dónde se va el tiempo. Pide ver un informe anterior sin el nombre ni los datos del cliente, y espera un diagnóstico, no una reconstrucción
• Proveedores de componentes, cuando la pieza que necesitas funciona igual para todos y tu ventaja está en otra parte. Venden una pieza ya hecha, como un matching engine o una conexión con un exchange, que operas tú en lugar de encargar la tuya propia. Pregunta entre qué puntos se midieron sus cifras de latencia y qué puedes cambiar en el código que licencias
• Empresas generalistas de outsourcing con un equipo de baja latencia identificado, cuando necesitas muchos ingenieros y la ruta rápida es una parte pequeña del trabajo. Pide los nombres de las personas de ese equipo y qué construyó cada una en tu rango, y consigue por escrito que trabajarán en tu proyecto
• Contrataciones propias, cuando la velocidad es tu forma de competir y lo seguirá siendo, y puedes reclutar y retener a ingenieros que ya han llevado a producción este tipo de sistema. Acuiti, una empresa de investigación, preguntó a 50 hedge funds sistemáticos, fondos que operan mediante modelos informáticos, cómo construyen su tecnología de trading. En enero de 2023 informó de que la latencia «es el factor clave que determina la actitud ante la externalización de la tecnología de front office, y las firmas para las que la latencia es crítica son más propensas a desarrollarla internamente»

Muchas empresas encajan en más de un tipo, así que pregunta qué tipo de trabajo han hecho los ingenieros que te asignen.

¿Cómo comprobamos que una empresa ya ha construido antes sistemas rápidos?

El artículo sobre equipos dedicados, enlazado arriba, enumera lo que debería acompañar a cada cifra de rendimiento y da una lista de comprobación que puedes pegar en una solicitud de propuestas. Las preguntas de abajo sirven para averiguar cómo se obtuvieron las cifras propias de una empresa.

Pregunta dónde empieza a contar el reloj y dónde se detiene. OPRA, que publica las operaciones y cotizaciones consolidadas de los exchanges de opciones de Estados Unidos, pone en marcha su reloj cuando un mensaje entrante «llega a la entrada de la aplicación del entorno de OPRA» y lo detiene cuando el mensaje saliente «llega a la salida de la aplicación del entorno de OPRA». La definición de la UE citada arriba es igual de precisa sobre ambos puntos. Una cifra que no nombra sus puntos de inicio y fin no se puede comparar con la tuya.

Mira las respuestas más lentas además de la típica. En las métricas publicadas por OPRA, la latencia mediana, el valor central, fue de 19.5 microsegundos en enero de 2024 y de 20.5 en febrero. En esos mismos dos meses, el percentil 99, el tiempo que solo superó el 1 por ciento más lento de los mensajes, bajó de 543.5 microsegundos a 57.5. Un informe solo con la mediana apenas habría mostrado cambios.

Las medias también esconden las respuestas lentas. El libro Site Reliability Engineering de Google, publicado por O'Reilly en 2016, describe un servicio web con una latencia media de 100 milisegundos a 1000 solicitudes por segundo, en el que «el 1% de las solicitudes podría tardar fácilmente 5 segundos». Pide el percentil 99 de cada ruta y, si tu sistema gestiona suficientes solicitudes para medirlo, el 99.9, que solo supera 1 de cada 1000 respuestas.

Comprueba la carga que hay detrás de cada cifra. En el resumen de STAC de 2020, STAC-T0 envía su tráfico de prueba a tres ritmos. El más bajo está «diseñado para ver cómo se comportan los sistemas cuando están mayormente inactivos», y el más alto, normalmente cerca del máximo que puede soportar el sistema probado, está ahí «para ver cómo se comportan los sistemas cuando están muy ocupados». Pide cifras de tu propio minuto de más carga, o de una prueba que lo reproduzca.

Pregunta cómo se hizo la prueba de carga. Muchas herramientas de pruebas de carga envían una solicitud, esperan la respuesta y solo entonces envían la siguiente. Cuando el sistema se atasca, una herramienta así deja de enviar, de modo que las solicitudes que habrían llegado durante el atasco nunca se miden.

Gil Tene, autor de la herramienta de pruebas de carga wrk2, llama a este efecto coordinated omission. En la documentación de la herramienta, modificada por última vez en septiembre de 2019, escribe que «las respuestas de alta latencia hacen que el generador de carga se coordine con el servidor para evitar medir durante los periodos de alta latencia». Su herramienta envía solicitudes a un ritmo fijo y mide cada respuesta «desde el momento en que debería haberse producido la transmisión». Pregunta si la herramienta de la empresa funciona así, o cómo se corrigieron sus resultados.

Pregunta dónde se tomó cada marca de tiempo. Para latencias en microsegundos, el resumen de STAC considera que un benchmark con marcas de tiempo por software es «la mejor opción». También advierte de que los retrasos pequeños e irregulares de las marcas de tiempo por software «pueden suponer un error considerable al medir latencias de decenas o cientos de nanosegundos», y STAC-T0, en cambio, toma sus marcas de tiempo por hardware. Una empresa que cita nanosegundos debería poder mostrar dónde se tomaron sus marcas de tiempo por hardware.

¿Qué prueba deberíamos hacer antes de contratar a nadie?

Si todavía no sabes qué falla, solo que el sistema parece más lento o cuesta más de lo que debería, empieza por aquí. Paga a la empresa que prefieras una medición de alcance cerrado de tu sistema en producción, con un informe que sea tuyo decidas lo que decidas después. Acuerda por escrito qué puede instalar o cambiar la empresa para tomar sus mediciones y cómo se retiran después sus herramientas.

El informe debería mostrar:

• A dónde se va el tiempo en tu minuto de más carga, paso a paso a lo largo de la ruta que anotaste
• Para cada ruta, los tiempos de respuesta en los percentiles 99 y 99.9
• Los arreglos, ordenados por lo que cuesta cada uno y lo que elimina, ya sea tiempo en la ruta o servidores que se añadieron para disimular una ruta lenta
• Lo que la empresa no tocaría, y por qué

Para los sistemas de trading, el artículo sobre la ejecución lenta de órdenes, enlazado arriba, enumera las cuatro marcas de tiempo que hay que registrar en cada orden. En ad tech, los artículos sobre picos de tráfico y sobre los timeouts de una DSP tratan qué medir en un pico y en cada conexión con un exchange.

Juzga a la empresa por su informe. Si tus propios ingenieros pueden actuar a partir de él sin la empresa, podrás elegir con cifras reales quién hace el trabajo siguiente, sea esta empresa u otra.

¿Cuáles son las señales de alarma al elegir una empresa de baja latencia?

• Velocidad descrita con palabras, sin cifra y sin puntos de inicio y fin
• Solo medias, sin nada sobre las respuestas más lentas
• Un benchmark del laboratorio de la propia empresa, ejecutado en su hardware con tráfico generado por ella, presentado como prueba sobre tu sistema
• Una reescritura, o el paso a un nuevo lenguaje de programación, propuestos antes de que nadie haya medido tu sistema
• Una cifra de latencia prometida en la primera llamada
• El mismo discurso comercial para un trabajo de trading medido en microsegundos y para un bidder publicitario con un deadline de 100 milisegundos

Si una empresa propone un lenguaje nuevo, el artículo enlazado abajo muestra cómo comprueban los ingenieros si la causa es el lenguaje.

¿Dónde encaja amBrain?

amBrain diagnostica sistemas lentos en trading y ad tech: la plataforma en funcionamiento se mide de extremo a extremo y el informe indica a dónde se va el tiempo. Su trabajo en trading incluye desarrollo de terminales de trading, sistemas de gestión de órdenes e integración con exchanges por protocolo FIX.

En AdTech, amBrain trabaja en desarrollo de DSP, plataformas de real-time bidding e ingeniería de ad exchange.

amBrain trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. El cliente conserva la propiedad completa del producto y del código, salvo los componentes reutilizables de amBrain.

amBrain desarrolla software desde 2019.

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes. No cita cifras de latencia de ningún sistema construido por amBrain, ni precios ni plazos.

Pregunta a amBrain, o a cualquier otra empresa de tu lista, qué mediría primero en tu sistema, y somete a todas las empresas a las mismas comprobaciones.

Preguntas frecuentes

• ¿Deberíamos formar nuestro propio equipo en su lugar? En el estudio de Acuiti de 2023 sobre 50 hedge funds sistemáticos, aquellos para los que la latencia es crítica eran más propensos a desarrollar internamente su tecnología de trading. Mide primero en cualquier caso, porque el informe te dice qué tipo de ingeniero contratar o qué pedirle a una empresa que haga
• ¿Puede una sola empresa cubrir tanto trading como ad tech? Puede, si tiene sistemas en producción en tu rango en ambos campos. Pide un sistema en producción en cada campo y comprueba sus cifras con las preguntas de arriba