Empresas de desarrollo en Rust para plataformas de trading y motores de casación: qué partes necesitan Rust y cómo contratar un equipo dedicado

Busca una empresa cuyos propios ingenieros hayan construido en Rust un motor de casación u otra parte de la ruta de la orden y lo mantengan funcionando en producción. Antes de firmar, conoce a las personas que se unirían a tu equipo. Rust se justifica donde un retraso cuesta dinero: el motor de casación, los controles de riesgo pre-trade, los gateways a los exchanges y el manejador de datos de mercado. Las pantallas, los informes y las herramientas de back office pueden seguir en los lenguajes que tu empresa ya usa.

¿Qué empresas se especializan en plataformas de trading y motores de casación en Rust?

Este artículo no clasifica empresas. Una especialista es una empresa cuyos propios ingenieros ya han entregado un sistema de trading en Rust y lo operan para un cliente. Una empresa que contrataría a sus ingenieros de Rust después de que firmes te está ofreciendo, en cambio, un plan de contratación.

El código de trading suele ser privado: normalmente lo posee el cliente y lo mantiene así, de modo que una empresa sólida puede tener poco código de trading en GitHub. Pide en su lugar que te describan de principio a fin un sistema en producción: qué hace, qué partes están escritas en Rust, cómo se mide su velocidad, quién lo opera hoy y qué falló después del lanzamiento. Si un acuerdo de confidencialidad oculta el nombre del cliente, pide a la empresa que organice una llamada con ese cliente.

Después revisa a las personas. Pide los nombres y la experiencia en Rust de los ingenieros que trabajarían en tu sistema, y habla con ellos antes de firmar. El artículo sobre equipos dedicados, enlazado más arriba, cubre las comprobaciones generales: código público, una prueba pagada y una revisión por un ingeniero independiente.

¿Qué partes de una plataforma de trading deberían escribirse en Rust?

Las que están en la ruta de una orden, donde una pausa de unos pocos milisegundos puede cambiar el precio que obtiene un cliente:

• El motor de casación, que empareja órdenes de compra y de venta por precio y momento de llegada
• Los controles de riesgo pre-trade, que detienen una orden que incumple un límite antes de que llegue al mercado
• Los gateways que envían órdenes a exchanges o brókers y reciben sus respuestas
• El manejador de datos de mercado, que lee los flujos de precios y transmite cada actualización

Rust encaja en estas partes porque libera memoria sin recolector de basura. Algunos lenguajes usan uno para esta tarea, y puede pausar el programa en el momento que él mismo elija. El libro de Rust (la guía oficial del lenguaje, consultada el 27 de octubre de 2026) dice que el ownership, el conjunto de reglas que lo hace posible, «permite a Rust dar garantías de seguridad de memoria sin necesitar un recolector de basura».

El lenguaje por sí solo no hace rápido un sistema. Un programa en Rust aún puede detenerse para pedir memoria, esperar un lock que tiene otro hilo o esperar a la red. El artículo sobre el diseño de un motor de casación explica cómo un equipo mantiene todo esto fuera de la ruta de la orden.

El resto de la plataforma no tiene un plazo que se mida en milisegundos: las pantallas web y móviles, las cuentas de clientes, los informes, el back office y las herramientas de administración. Pueden seguir en los lenguajes que ya usan tus desarrolladores o tus proveedores. Una empresa que proponga reescribirlos en Rust debería explicar qué ganas con ello.

Ya tenemos una plataforma en C++, Java o Go. ¿Deberíamos reescribirla en Rust?

Normalmente no de una vez. Un camino más seguro es mover un componente con un límite claro, como los controles de riesgo o el manejador de datos de mercado, y dejar el resto como está.

El nuevo componente puede funcionar como un servicio aparte que intercambia mensajes con el resto del sistema. También puede construirse como una biblioteca que el código en C o C++ llama directamente. El Rustonomicon, la guía del proyecto Rust sobre código unsafe y de bajo nivel, explica cómo hacerlo en una sección titulada «Calling Rust code from C».

Antes del cambio, ejecuta el nuevo componente junto al antiguo con el mismo flujo de órdenes grabado y compara cada resultado. Un motor de casación determinista siempre da el mismo resultado para las mismas órdenes en la misma secuencia. Eso hace que la comparación sea sencilla: si ambos motores aplican las mismas reglas, cualquier diferencia apunta a un error en uno de ellos.

Después pasa un mercado o un grupo de instrumentos cada vez, y ten el componente antiguo listo para recuperar el tráfico.

¿Qué incluye un equipo dedicado externo de Rust para un motor de casación?

Un equipo dedicado trabaja solo en tu sistema durante meses o años, y sus miembros cambian solo cuando tú lo aceptas. Para un motor de casación u otra parte de la ruta de la orden, suele incluir:

• Ingenieros de Rust que han llevado código a producción y saben cómo vive una orden: tipos de órdenes, ejecuciones parciales, modificaciones y cancelaciones
• Un ingeniero líder que se responsabiliza del diseño y revisa cada cambio en la ruta de la orden
• Un ingeniero de pruebas que monta el entorno que reproduce el flujo de órdenes grabado y comprueba los resultados
• Alguien responsable de los servidores, la configuración de red y las publicaciones

Tu empresa también tiene un papel. Alguien de tu lado decide las reglas de negociación, como el tamaño del tick, el horario de negociación, las comisiones y qué ocurre cuando se detiene la negociación, y responde a las preguntas del equipo sobre ellas sin grandes demoras.

Los freelancers pueden ser ingenieros excelentes, pero con ellos la continuidad es más difícil. Un contratista individual no tiene a nadie que revise los cambios en la ruta de la orden, y cuando esa persona se va, lo que sabía de tu sistema se va con ella. Una empresa puede sustituir a alguien y conservar el conocimiento en el equipo, y el contrato puede exigírselo.

Una empresa solo puede dimensionar el equipo después de ver tus reglas de negociación, tus mercados y tus volúmenes, así que pregunta cómo llegó a la cifra que propone.

¿Qué deberíamos preguntar a un equipo de Rust sobre un motor de casación?

El artículo sobre empresas de baja latencia explica cómo comprobar las cifras de velocidad. Estas preguntas tratan de Rust y de la ruta de la orden:

• ¿Dónde usa unsafe su código y quién revisa esas partes?
• ¿Cómo prueban el motor, además de reproducir órdenes grabadas?
• ¿De qué crates depende la ruta de la orden y cómo comprueban si tienen vulnerabilidades conocidas?
• ¿Con qué versión de Rust compilan y cómo deciden cuándo actualizar?
• ¿Quién del equipo propuesto ha llevado Rust a producción, en qué sistema y sigue funcionando?

Rust comprueba cómo se usa la memoria al compilar el código. Dentro de un bloque marcado como unsafe, el código puede hacer cinco cosas que el compilador de otro modo rechaza, como seguir un puntero crudo hasta la memoria. El libro de Rust añade que unsafe «no desactiva el borrow checker ni ninguna de las demás comprobaciones de seguridad de Rust». Una buena respuesta indica dónde está el código unsafe, por qué hace falta ahí y quién lo revisó.

En cuanto a las pruebas, un equipo debería nombrar las herramientas que usa. cargo-fuzz, que el Rust Fuzz Book llama «la herramienta recomendada para hacer fuzz testing de código Rust», alimenta un programa con grandes cantidades de entradas generadas para encontrar los casos que lo hacen fallar. Loom, una biblioteca para probar código que se ejecuta en varios hilos, «ejecuta las pruebas muchas veces, permutando las posibles ejecuciones concurrentes de cada prueba». Así se encuentran errores que solo aparecen cuando los hilos se ejecutan en un orden desafortunado.

Los crates son los paquetes de código compartido de Rust. La RustSec Advisory Database registra avisos de seguridad sobre crates publicados en crates.io. Su herramienta cargo-audit revisa el Cargo.lock de un proyecto, el archivo que enumera la versión exacta de cada dependencia, «en busca de crates con vulnerabilidades de seguridad». Un equipo que trabaja en una ruta de órdenes debería poder decirte si esa comprobación se ejecuta en cada compilación.

Rust publica una nueva versión estable cada seis semanas, y el libro de Rust dice que «nunca deberías temer actualizar a una nueva versión de Rust estable». Aun así, un equipo puede mantener todas las compilaciones en una versión elegida. La documentación de rustup, el instalador de Rust, describe un archivo de toolchain para los proyectos que se ven «“fijados” a una versión concreta de Rust» y quieren dejarlo registrado en su repositorio. En una ruta de órdenes, la versión solo debería cambiar a propósito, después de que pasen las pruebas.

¿Qué debe decir el contrato con un equipo de Rust?

Incluye en él estos puntos:

• El código, las pruebas, los datos de reproducción y los scripts de compilación están en repositorios que pertenecen a tu empresa
• Las compilaciones y las publicaciones se ejecutan en cuentas abiertas a nombre de tu empresa
• Quién puede cambiar la ruta de la orden y quién revisa cada cambio
• Las horas que cubre el equipo, y quién responde si el motor falla fuera de ellas
• Qué recibes si el contrato termina: documentación, accesos y tiempo del equipo para hacer el traspaso al siguiente

¿Dónde encaja amBrain?

amBrain, que publica este blog, se describe en una línea: «amBrain es una empresa de ingeniería de software de Ereván, Armenia, que construye plataformas de trading de baja latencia, motores de casación y sistemas de real-time bidding en Rust». Otra línea dice: «amBrain construye infraestructura de trading algorítmico: ejecución de órdenes, datos de mercado y controles de riesgo pre-trade».

amBrain desarrolla software desde 2019. Describe su equipo con sus propias palabras: «Un equipo de hasta 40 personas, alrededor del 75% de ellas senior». Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables».

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes. No dice qué sistemas ha construido amBrain en Rust ni para quién, y no da precios, plazos ni tamaños de equipo de amBrain. Si amBrain está en tu lista corta, hazle las mismas preguntas que a cualquier otra empresa.