Der Bedarf an Geschwindigkeit: Wie DecisionRules Druck wie ein Profi bewältigt

Seien wir ehrlich: Leistungsengpässe sind die stillen Killer der digitalen Transformation.

Sie treten nicht mit einem dramatischen Absturz auf. Sie schleichen sich leise ein, getarnt als verzögerte Dashboards, Zeitüberschreitungen, langsame Regelabläufe und das gefürchtete „Bitte warten…“, genau dann, wenn es am wichtigsten ist. Leistung ist in jeder Branche entscheidend. Geschwindigkeit zählt, egal ob Sie im Finanzdienstleistungssektor, in der Versicherungsbranche, im Gesundheitswesen, im E-Commerce oder im Transportwesen tätig sind. Müssen Sie Dinge schneller genehmigen? Müssen Sie dynamisch preisen? Müssen Sie in Echtzeit über Dutzende komplexer Bedingungen hinweg berechnen? Hohe Leistung in Ihren Geschäftsprozessen ist nicht nur schön zu haben, sie ist unerlässlich. Wenn Ihr Unternehmen schnell vorankommt, hat Ihre Entscheidungsmaschine nur einen Job:

Halten Sie Schritt und brechen Sie nicht zusammen.

Also haben wir die Tests durchgeführt. Nicht nur ein paar Rauchtests, sondern vollständige Lastsimulationen. Wir haben 600 virtuelle Benutzer auf unsere Logikmaschine losgelassen. Wir haben Entscheidungstabellen, Bäume, Skripte und Regelabläufe über drei verschiedene Infrastrukturstufen hinweg benchmarked und dabei in jedem Schritt echte Protokolle erfasst.

Denn Theorie ist nett, aber Leistung ist der Beweis.

Vor den interessanten Dingen

Es gibt zwei Konzepte, die wir erklären möchten, bevor wir tiefer eintauchen.

Was ist ein „Worker“?

‍Denken Sie an einen Worker als die Person, die die eigentliche Arbeit verrichtet. Jedes Mal, wenn Ihr System eine Entscheidung treffen muss, wie z. B. einen Preis zu berechnen oder die Berechtigung zu überprüfen, übernimmt ein Worker diese Aufgabe. Je mehr Worker Sie haben, desto mehr Entscheidungen können Sie gleichzeitig verarbeiten.

**Was ist eine „Instanz“?**‍

Das ist einfach der Computer (virtuell oder physisch), auf dem die Worker leben. Sie können einen Worker auf einem Computer haben oder mehrere. Sie können auch mehrere Computer haben, jeder mit seinen eigenen Workern.

Lassen Sie uns über Zahlen sprechen

So haben sich die einzelnen Stufen pro Worker und pro Minute geschlagen. (Die Advanced-Stufe verwendete 2 Worker, daher sind die Gesamtwerte pro Instanz verdoppelt)

Selbst in unseren anspruchsvollsten Tests der Advanced-Stufe lagen die komplexen Regelabläufe zwischen 210-1000 ms, während leichte Tabellen und Bäume konstant unter 20 ms Latenz blieben.

Aber nicht alles ist eine kleine Regel, und zu Spitzenzeiten haben wir über 39 Millionen Anfragen in 10 Minuten verarbeitet, ohne einen einzigen systemweiten Ausfall.

Was wir getestet haben (und warum es wichtig ist)

Wir haben 3 realistische Setups von grundlegenden Konfigurationen bis hin zu produktionsbereiten Umgebungen modelliert, um die Arten von Bereitstellungen genauer widerzuspiegeln, die Unternehmen tatsächlich verwenden.

Aber bevor wir zu den Testergebnissen kommen, hier sind zwei Begriffe, mit denen Sie vertraut sein sollten. Ich verspreche, das sind die letzten Definitionen, die Sie lesen müssen.

Was ist „Redis“?

‍Das ist wie ein Hochgeschwindigkeits-Notizblock. Es hilft dem System, Ergebnisse schnell zu speichern, die es bereits gesehen hat, damit es wiederholte Fragen viel schneller beantworten kann.

Was ist „In-Memory-Cache“?

‍Es ist eine Möglichkeit, häufig benötigte Daten direkt an den Fingerspitzen des Workers zu halten, anstatt sie erneut abzurufen. Es ist, als hätte man seine 10 wichtigsten Berichte immer auf dem Schreibtisch offen, anstatt sie in einem Aktenschrank zu lagern.

Jetzt, da Sie wissen, was unter der Haube vor sich geht, hier ist, wie wir die drei getesteten Leistungsstufen strukturiert haben:

Wir haben m7i.2xlarge Maschinen verwendet, um 600 Benutzer zu simulieren, die über 10 Minuten hochgefahren werden.

Die Ergebnisse? Schnell, skalierbar und stabil. Egal wie komplex die Logik oder wie hoch die Last ist.

Geschwindigkeitstest: Entscheidungstabellen für Volumen

Um zu sehen, wie schnell das System unter Druck arbeiten kann, haben wir eine reale Preisregel verwendet, die unsere Produktkatalog-Entscheidungstabelle ist. Dies ist die Art von Regel, die Sie im E-Commerce oder bei der Produktkonfiguration verwenden würden. Sie simulierte hochvolumige Preisprüfungen mit echter Geschäftslogik.

Hier ist, was die Engine auf der Normal-Stufe mit 600 virtuellen Benutzern bewältigte:

‍

Das sind über 3,1 Millionen erfolgreiche Entscheidungen ohne Fehler und eine durchschnittliche Zeit von unter 60 Millisekunden pro Anfrage.

„Das ist die Art von Geschwindigkeit, die Sie hinter Preis-Engines, Konfiguratoren und Live-API-Endpunkten wollen, die schnell, vorhersehbar und skalierbar sind.”

Schwierige Regelabläufe, kein Problem

Wir haben etwas Schwereres gestresst: die Parallel-Auto-Approval-Regel-Orchestrierung. Dies ist ein Regelset, das verwendet wird, um zu bestimmen, ob Angebote von Finanzinstituten automatisch genehmigt werden sollten oder auf manuelle Prüfung zurückfallen. Die Logik umfasst:

• Unterschiede zwischen erwarteter und angebotener APR
• Ob bestimmte Geldgeber einen Einkommensnachweis benötigen
• Dynamische Bedingungen wie „Einkommensnachweis erforderlich“
• Alles parallel über 40+ Finanzierungsquellen

Das ist kein einfaches „Wenn-Dann“-Szenario, es ist echte Entscheidungsautomatisierung, die von verschiedenen Parametern über Geldgeber, Vermittler und Endverbraucher gesteuert wird.

Das sind über 321.000 Iterationen, fast 650.000 erfolgreiche Validierungen und nur 4 Antworten, die korrigiert werden mussten.

Noch besser? Überwachungswerkzeuge fielen aus (StatsD-Verbindung abgelehnt), aber die Logik-Engine machte keinen Fehler.

„Die Beobachtbarkeit brach zusammen. Die Regel-Engine lief weiter. Das ist die Art von Stabilität, die in der Produktion zählt.”

Skalierung richtig gemacht

Es gibt einen weit verbreiteten Mythos: Wenn die Leistung nachlässt, werfen Sie einfach eine größere Maschine darauf. Mehr CPUs! Mehr Leistung! Mehr… Probleme.

Hier ist, was Ihnen niemand sagt:

• 1 Arbeiter = 1 CPU-Kern

Sie könnten eine riesige 12-Kern-Instanz hochfahren. Das nennt man vertikale Skalierung und es funktioniert… Aber es ist, als würde man eine Person einstellen, um alles schneller zu erledigen, anstatt ein Team aufzubauen.

Wir bevorzugen die horizontale Skalierung:

• Anstatt einen großen Computer zu verwenden, mehrere kleine nutzen
• Jeder mit seinem eigenen speziellen Job (oder „Arbeiter“)
• Wenn einer langsamer wird, laufen die anderen weiter

1 Instanz mit 1 Arbeiter für Basic und Normal und 2 Arbeiter für Advanced.

• Gleiche Gesamt-Rechenleistung
• Weniger Konkurrenz
• Bessere Fehlertoleranz
• Sanftere Skalierung unter Last

Dies ermöglicht es Ihnen, von der Bearbeitung von wenigen Anfragen pro Minute auf Millionen pro Stunde zu wachsen, ohne dramatische Infrastrukturänderungen. Der horizontal-first Ansatz stellt sicher, dass DecisionRules mit Ihren Bedürfnissen wächst. Von Hunderten von Anfragen pro Minute zu Millionen pro Stunde mit Konsistenz und Vorhersehbarkeit.

Produktionsbereit, keine Überraschungen

Wir haben nicht bei idealen Umgebungen Halt gemacht. Wir haben auch ältere und niedrigere Setups getestet:

• Regelabläufe, die einst bei 300 Benutzern abstürzten, laufen jetzt fehlerfrei bei über 600
• Entscheidungstabellen, die in 600 Millisekunden reagierten, feuern jetzt in 13 Millisekunden
• Bäume und Tabellen mit Tausenden von Zweigen bleiben unter 20 Millisekunden im Median bei Skalierung

Egal, ob Sie DecisionRules zur Unterstützung interner Automatisierungen oder kundenorientierter Regelabläufe verwenden, Sie erhalten vorhersehbare Leistung über Umgebungen hinweg.

Letztes Wort: Vorhersehbare Leistung, nach Ihren Bedingungen

Wir bauen nicht nur eine Business Rule Engine. Wir bauen ein System, das:

• Analysten ermächtigt, Logik in Minuten ohne Entwicklerhilfe zu bearbeiten

• Selbstbewusst skaliert über Anwendungsfälle und Verkehr ohne Ausfallzeiten

• Liefern kann, selbst wenn Teile Ihres Systems ausfallen

Egal, ob Sie Rabatt-Engines, Versicherungspreise, Provisionsmodelle oder regulatorische Logik automatisieren, DecisionRules ist bereit, wenn Ihr Unternehmen es am meisten braucht.

Denn wenn jede Entscheidung zählt, sollte Ihre Engine das auch tun.