Von Natur aus effizient: warum wir wie Faultiere bauen

Das Faultier ist nicht faul. Es ist optimiert.

Ein Dreizehen-Faultier verbrennt pro Kilogramm Körpergewicht etwa zehnmal weniger Kalorien als ein Säugetier vergleichbarer Größe. Jede Bewegung ist bewusst. Jede Kalorie wird berücksichtigt. Das Ergebnis ist ein Tier, das seit rund 64 Millionen Jahren nahezu unverändert überlebt — nicht weil es das Schnellste oder Stärkste ist, sondern weil es kaum etwas verschwendet.

Als wir Slothlike konzipierten, wurde diese Stoffwechsel-Effizienz unser Leitstern. Die Frage war nie Wie schnell können wir Features liefern?, sondern Wie wenig müssen wir verbrauchen, um genau das zu liefern, was gebraucht wird?

Wir haben Rust nicht gewählt, weil es modern ist, sondern weil sein Kostenmodell zu unserem passt.

Ein kompiliertes Rust-Binary enthält keine Laufzeitumgebung, keine Garbage-Collector-Pausen und keinen versteckten Heap-Overhead. Die Docker-Images von RDataCore sind klein, und seine Prozesse belegen im Leerlauf einen Bruchteil dessen, was ein JVM-basierter Stack benötigen würde. Die Antwortzeiten im 99. Perzentil liegen auch unter anhaltender Last im niedrigen einstelligen Millisekundenbereich — nicht weil wir mehr Hardware eingesetzt haben, sondern weil die Sprache Verschwendung strukturell unmöglich macht.

Das Rust-Ownership-Modell zwingt dazu, über Ressourcenbesitz und Freigabezeitpunkt nachzudenken. Diese Disziplin, anfangs unbequem, zahlt sich über ein langes Projekt mit Zinseszins aus: kein Use-after-free, keine Datenwettläufe, keine Überraschungsallokationen in der Produktion.

Für ein Produkt, das viele Kunden auf bescheidenen VPS-Instanzen selbst hosten, zählt dieser Footprint. RDataCore läuft problemlos auf einer Maschine, auf der eine JVM-basierte Alternative kaum starten würde.

Effizienz im Rechenbereich ist bedeutungslos, wenn der Code, der sie erzeugt, ein Wirrwarr ist. Langsamer Code verottet schnell.

Wir halten uns an einen einfachen Grundsatz: Jeder nicht-triviale Codepfad ist durch einen Test abgedeckt, und jeder Test ist schnell genug, um bei jedem Commit ausgeführt zu werden. Unsere CI-Pipeline schließt in unter zwei Minuten ab, sodass Entwickler Rückmeldung erhalten, bevor der Kontext verloren geht.

Code-Reviews haben eine primäre Frage: Ist das die einfachste Sache, die möglicherweise funktionieren könnte? Wenn die Antwort Nein ist, fragen wir warum nicht. Cleverer Code ist eine Verbindlichkeit. Offensichtlicher Code ist ein Vorteil.

Hohe Abdeckung bedeutet nicht 100 % Zeilenabdeckung. Es bedeutet, dass die Fehlermodi, die wichtig sind — Authentifizierungslogik, Datenintegritätsinvarianten, Workflow-Grenzen — kontinuierlich getestet werden. Ein Fehler, der durch dieses Netz schlüpft, ist eine Lücke in unserem Verständnis, und diese Lücke zu schließen ist wertvoller als das Erreichen eines beliebigen Prozentsatzes.

Wir bauen offen, weil Intransparenz Overhead ist.

Wenn ein Kunde einen Fehler meldet, bedeutet ein öffentliches Repository, dass er den relevanten Code lesen, das Problem reproduzieren und manchmal einen Patch einsenden kann, bevor wir die Triage abgeschlossen haben. Das ist eine Hebelwirkung, auf die wir törichterweise verzichten würden.

Open Source erzwingt auch eine nützliche Disziplin: Code, der von Fremden gelesen werden wird, ist sorgfältiger geschrieben als Code, der nur in einem privaten Repository lebt. Der imaginäre Leser ist ein guter Lektor.

Nicht alle unsere Software trägt eine permissive Lizenz. RDataCore wird unter einem eigenen Business Licence Agreement veröffentlicht — einer source-available kommerziellen Lizenz. My Family Tree erscheint unter BUSL-1.1. Viele Kundenlösungen bleiben vollständig proprietär, weil Kunden ihre Prozesse und Datensätze privat halten wollen. Wir sind ehrlich damit: offen als Standard, wo es sinnvoll ist — source-available oder proprietär, wo die Situation es erfordert.

Das schwierigste Problem in der Unternehmenssoftware ist nicht das Aufbauen neuer Systeme — es ist das Koexistieren mit bestehenden.

Slothlikes Kerngedanke ist, sich in bestehende Systeme zu integrieren, statt sie zu ersetzen. Wir behandeln RDataCore als die Master-Data-Schicht: Entity-Definitionen, Hierarchien, Workflow-Pipelines und die öffentliche API verbleiben in RDataCore, genau so wie der Kunde sie bereits konfiguriert hat. Darüber bauen wir eine dünne Präsentations- und Orchestrierungsschicht — maßgeschneiderte Frontends, Automatisierungsskripte und Integrations-Bridges — passend auf jeden Client-Stack zugeschnitten.

Das bedeutet keine schmerzhaften Migrationen, keine „Lift and Shift”-Projekte, die Quartale statt Wochen dauern, und keinen Single Point of Failure. Wenn ein Kunde bestimmte Workflows durch ein Legacy-System leiten muss, kann er das. Die Architektur erwartet Heterogenität.

Das Faultier überlebt, weil es mit dem Blätterdach arbeitet, das es hat, nicht mit dem, das es sich vorstellt. Wir versuchen das Gleiche zu tun.