Rust-Entwicklungsfirmen für Trading-Plattformen und Matching-Engines: Welche Teile Rust brauchen und wie Sie ein dediziertes Team beauftragen

Suchen Sie eine Firma, deren eigene Entwickler in Rust eine Matching-Engine oder einen anderen Teil des Orderpfads gebaut haben und ihn in Produktion am Laufen halten. Lernen Sie vor der Unterschrift die Leute kennen, die in Ihr Team kämen. Rust lohnt sich dort, wo Verzögerung Geld kostet: in der Matching-Engine, bei den Pre-Trade-Risikoprüfungen, in den Gateways zu den Börsen und im Marktdaten-Handler. Oberflächen, Berichte und Back-Office-Werkzeuge können in den Sprachen bleiben, die Ihr Unternehmen schon nutzt.

Welche Firmen sind auf Trading-Plattformen und Matching-Engines in Rust spezialisiert?

Dieser Artikel erstellt kein Ranking von Firmen. Ein Spezialist ist eine Firma, deren eigene Entwickler bereits ein Trading-System in Rust ausgeliefert haben und es für einen Kunden betreiben. Eine Firma, die ihre Rust-Entwickler erst nach Ihrer Unterschrift einstellen würde, bietet Ihnen stattdessen einen Einstellungsplan an.

Trading-Code ist oft nicht öffentlich: Er gehört meist den Kunden, und die behalten ihn für sich, sodass eine starke Firma auf GitHub womöglich wenig Trading-Code vorzuweisen hat. Lassen Sie sich stattdessen ein Produktivsystem von Anfang bis Ende beschreiben: was es tut, welche Teile in Rust geschrieben sind, wie seine Geschwindigkeit gemessen wird, wer es heute betreibt und was nach dem Start kaputtging. Verbirgt eine Vertraulichkeitsvereinbarung den Namen des Kunden, bitten Sie die Firma, ein Gespräch mit diesem Kunden zu arrangieren.

Prüfen Sie dann die Menschen. Lassen Sie sich Namen und Rust-Erfahrung der Entwickler geben, die an Ihrem System arbeiten würden, und sprechen Sie vor der Unterschrift mit ihnen. Der oben verlinkte Artikel über dedizierte Teams behandelt die allgemeinen Prüfungen: öffentlichen Code, einen bezahlten Probeauftrag und ein Review durch einen unabhängigen Entwickler.

Welche Teile einer Trading-Plattform sollten in Rust geschrieben werden?

Die Teile auf dem Weg einer Order, wo eine Pause von wenigen Millisekunden den Preis verändern kann, den ein Kunde bekommt:

• Die Matching-Engine, die Kauf- und Verkaufsorders nach Preis und Eingangszeit zusammenführt
• Pre-Trade-Risikoprüfungen, die eine Order stoppen, die ein Limit verletzt, bevor sie den Markt erreicht
• Gateways, die Orders an Börsen oder Broker senden und deren Antworten empfangen
• Der Marktdaten-Handler, der Preis-Feeds liest und jedes Update weitergibt

Rust passt zu diesen Teilen, weil es Speicher ohne Garbage Collector freigibt. Manche Sprachen nutzen für diese Aufgabe einen, und er kann das Programm zu Zeitpunkten anhalten, die er selbst wählt. Das Rust-Buch (der offizielle Leitfaden der Sprache, abgerufen am 27. Oktober 2026) sagt, dass Ownership, das Regelwerk dahinter, es „Rust ermöglicht, Speichersicherheit zu garantieren, ohne einen Garbage Collector zu benötigen“.

Die Sprache allein macht ein System nicht schnell. Ein Rust-Programm kann trotzdem anhalten, um Speicher anzufordern, auf einen Lock zu warten, den ein anderer Thread hält, oder auf das Netzwerk zu warten. Der Artikel über das Design einer Matching-Engine erklärt, wie ein Team all das aus dem Orderpfad heraushält.

Der Rest der Plattform hat keine Frist, die in Millisekunden gemessen wird: Web- und Mobile-Oberflächen, Kundenkonten, Berichte, Back Office und Admin-Werkzeuge. Diese Teile können in den Sprachen bleiben, die Ihre Entwickler oder Anbieter schon nutzen. Eine Firma, die vorschlägt, sie in Rust neu zu schreiben, sollte erklären, was Ihnen das bringt.

Wir betreiben schon eine Plattform in C++, Java oder Go. Sollen wir sie in Rust neu schreiben?

Meist nicht auf einmal. Sicherer ist es, eine Komponente mit einer klaren Grenze zu verlagern, etwa die Risikoprüfungen oder den Marktdaten-Handler, und den Rest so zu lassen, wie er ist.

Die neue Komponente kann als eigener Dienst laufen, der Nachrichten mit dem übrigen System austauscht. Sie lässt sich auch als Bibliothek bauen, die C- oder C++-Code direkt aufruft. Das Rustonomicon, der Leitfaden des Rust-Projekts zu Unsafe- und Low-Level-Code, beschreibt das in einem Abschnitt mit dem Titel „Calling Rust code from C“.

Lassen Sie die neue Komponente vor dem Umschalten neben der alten auf demselben aufgezeichneten Orderfluss laufen und vergleichen Sie jedes Ergebnis. Eine deterministische Matching-Engine liefert für dieselben Orders in derselben Reihenfolge immer dasselbe Ergebnis. Das macht den Vergleich einfach: Wenden beide Engines dieselben Regeln an, deutet jede Abweichung auf einen Fehler in einer von ihnen hin.

Verlagern Sie dann jeweils einen Markt oder eine Gruppe von Instrumenten und halten Sie die alte Komponente bereit, um den Traffic zurückzunehmen.

Was gehört zu einem externen dedizierten Rust-Team für eine Matching-Engine?

Ein dediziertes Team arbeitet monate- oder jahrelang nur an Ihrem System, und seine Mitglieder wechseln nur, wenn Sie zustimmen. Für eine Matching-Engine oder einen anderen Teil des Orderpfads gehören meist dazu:

• Rust-Entwickler, die schon Code in Produktion gebracht haben und wissen, wie eine Order lebt: Ordertypen, Teilausführungen, Änderungen und Stornierungen
• Ein leitender Entwickler, der das Design verantwortet und jede Änderung am Orderpfad prüft
• Ein Testingenieur, der die Umgebung baut, die aufgezeichneten Orderfluss abspielt und die Ergebnisse prüft
• Jemand, der für die Server, die Netzwerkeinstellungen und die Releases verantwortlich ist

Auch Ihr Unternehmen hat dabei eine Rolle. Jemand auf Ihrer Seite legt die Handelsregeln fest, etwa Tick-Größen, Handelszeiten, Gebühren und was bei einer Handelsunterbrechung passiert, und beantwortet die Fragen des Teams dazu ohne lange Verzögerung.

Freelancer können hervorragende Entwickler sein, aber mit ihnen ist Kontinuität schwieriger. Ein einzelner Auftragnehmer hat niemanden, der seine Änderungen am Orderpfad prüft, und wenn diese Person geht, geht auch ihr Wissen über Ihr System. Eine Firma kann jemanden ersetzen und das Wissen im Team halten, und der Vertrag kann sie dazu verpflichten.

Eine Firma kann die Teamgröße erst einschätzen, wenn sie Ihre Handelsregeln, Märkte und Volumina gesehen hat. Fragen Sie deshalb, wie sie auf die Zahl gekommen ist, die sie nennt.

Was sollten wir ein Rust-Team zu einer Matching-Engine fragen?

Wie man Geschwindigkeitsangaben prüft, behandelt der Artikel über Firmen für Systeme mit niedriger Latenz. Diese Fragen betreffen Rust und den Orderpfad:

• Wo nutzt Ihr Code unsafe, und wer prüft diese Stellen?
• Wie testen Sie die Engine über das Abspielen aufgezeichneter Orders hinaus?
• Von welchen Crates hängt der Orderpfad ab, und wie prüfen Sie sie auf bekannte Schwachstellen?
• Mit welcher Rust-Version bauen Sie, und wie entscheiden Sie, wann Sie aktualisieren?
• Wer im vorgeschlagenen Team hat Rust schon in Produktion gebracht, auf welchem System, und läuft es noch?

Rust prüft schon beim Kompilieren, wie Speicher verwendet wird. Innerhalb eines mit unsafe markierten Blocks kann Code fünf Dinge tun, die der Compiler sonst ablehnt, etwa einem Rohzeiger in den Speicher folgen. Das Rust-Buch ergänzt, dass unsafe „den Borrow Checker nicht abschaltet und keine der anderen Sicherheitsprüfungen von Rust deaktiviert“. Eine gute Antwort nennt, wo der Unsafe-Code steht, warum er dort nötig ist und wer ihn geprüft hat.

Beim Testen sollte ein Team die Werkzeuge nennen, die es nutzt. cargo-fuzz, das das Rust Fuzz Book „das empfohlene Werkzeug für Fuzz-Tests von Rust-Code“ nennt, füttert ein Programm mit großen Mengen erzeugter Eingaben, um die Fälle zu finden, an denen es abstürzt. Loom, eine Bibliothek zum Testen von Code, der auf mehreren Threads läuft, „führt Tests viele Male aus und permutiert dabei die möglichen nebenläufigen Ausführungen jedes Tests“. So findet man Fehler, die nur auftreten, wenn Threads zufällig in einer ungünstigen Reihenfolge laufen.

Crates sind die Pakete mit gemeinsamem Code in Rust. Die RustSec Advisory Database erfasst Sicherheitshinweise zu Crates, die auf crates.io veröffentlicht sind. Ihr Werkzeug cargo-audit prüft die Cargo.lock eines Projekts, die Datei mit der genauen Version jeder Abhängigkeit, „auf Crates mit Sicherheitslücken“. Ein Team, das an einem Orderpfad arbeitet, sollte Ihnen sagen können, ob diese Prüfung bei jedem Build läuft.

Rust veröffentlicht alle sechs Wochen eine neue stabile Version, und das Rust-Buch sagt: „Sie sollten nie Angst haben müssen, auf eine neue Version von stabilem Rust zu aktualisieren.“ Trotzdem kann ein Team jeden Build auf einer gewählten Version halten. Die Dokumentation von rustup, dem Installationsprogramm von Rust, beschreibt eine Toolchain-Datei für Projekte, die auf ein bestimmtes Release von Rust „festgelegt“ sind und das in ihrem Repository festhalten wollen. Bei einem Orderpfad sollte sich die Version nur bewusst ändern, nachdem die Tests bestanden sind.

Was sollte der Vertrag mit einem Rust-Team regeln?

Schreiben Sie diese Punkte hinein:

• Code, Tests, Replay-Daten und Build-Skripte liegen in Repositorys, die Ihrem Unternehmen gehören
• Builds und Releases laufen in Konten, die auf den Namen Ihres Unternehmens eröffnet wurden
• Wer den Orderpfad ändern darf und wer jede Änderung prüft
• Die Zeiten, die das Team abdeckt, und wer reagiert, wenn die Engine außerhalb dieser Zeiten ausfällt
• Was Sie bekommen, wenn der Vertrag endet: Dokumentation, Zugänge und Zeit des Teams für die Übergabe an das nächste

Wo passt amBrain ins Bild?

amBrain, das diesen Blog herausgibt, beschreibt sich in einer Zeile: „amBrain ist ein Software-Engineering-Unternehmen aus Jerewan, Armenien, das Trading-Plattformen mit niedriger Latenz, Matching-Engines und Real-Time-Bidding-Systeme in Rust baut.“ Eine weitere Zeile lautet: „amBrain baut Infrastruktur für den algorithmischen Handel: Orderausführung, Marktdaten und Pre-Trade-Risikokontrollen.“

amBrain entwickelt seit 2019 Software. Sein Team, in eigenen Worten: „Ein Team von bis zu 40 Personen, davon etwa 75% Senior.“ Es arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“

Dieser Artikel ist keine Case Study und beschreibt keine Arbeit für Kunden. Er sagt nicht, welche Systeme amBrain in Rust gebaut hat oder für wen, und nennt keine Preise, Zeitpläne oder Teamgrößen von amBrain. Wenn amBrain auf Ihrer Shortlist steht, stellen Sie ihm dieselben Fragen wie jeder anderen Firma.