A/B-Testing in Rust: Wie man die Produktion nicht kaputt macht und die Wahrheit findet

Warum ist Rust ideal für A/B-Tests?

Wenn wir über A/B-Testing sprechen, denkt man normalerweise an Python, R oder JavaScript. Aber Rust ist ein dunkles Pferd, das sich in realen Kampfbedingungen als schneller, sicherer und günstiger erweist. Wenn Ihr Backend in Rust geschrieben ist, können Sie Experimente direkt in den Kern des Systems einbetten, ohne Overhead durch Microservices und Redis.

Stellen Sie sich vor: Sie ändern den Empfehlungsalgorithmus, die Farbe des "Kaufen"-Buttons oder die Parsing-Logik. Ein Fehler im Code eines A/B-Tests in Python kann den Server lahmlegen. In Rust – Sie kompilieren einfach nicht, wenn Sie einen Bedingungszweig übersehen. Der Compiler ist Ihr bester QA.

In diesem Artikel werden wir A/B-Testing in Rust von der Architektur bis zur Produktion durchgehen. Sie erfahren, wie Sie Split-Tests ohne Schmerz durchführen, Statistiken berechnen und keine Benutzer verlieren.

Architektur eines A/B-Tests in Rust: Drei Säulen

Jedes Experiment in einer Rust-Anwendung basiert auf drei Komponenten:

\n
• Randomisierer – wer kommt in Gruppe A, wer in B?
\n
• Zuweisungsspeicher – damit der Benutzer nicht bei jeder Anfrage zwischen den Gruppen springt.
\n
• Protokollierung und Statistik – wir berechnen Konversion und p-Wert.
\n

Schreiben wir ein einfaches, aber funktionsfähiges Modul. Keine Frameworks – nur Rust und seine Standardbibliothek.

Schritt 1. Randomisierung basierend auf Hash

Deterministische Randomisierung ist der Schlüssel zur Stabilität. Wenn Sie rand::random() verwenden, kann der Benutzer bei jedem Neustart des Servers in eine andere Gruppe springen. Wir verwenden einen gewichteten Hash aus der Benutzer-ID und dem Namen des Experiments.

use std::collections::hash_map::DefaultHasher;\nuse std::hash::{Hash, Hasher};\n\n#[derive(Debug, Clone, Copy, PartialEq)]\npub enum Group {\n    Control,\n    Treatment,\n}\n\npub fn assign_group(user_id: &str, experiment: &str, treatment_weight: f64) -> Group {\n    let mut hasher = DefaultHasher::new();\n    user_id.hash(&mut hasher);\n    experiment.hash(&mut hasher);\n    let hash = hasher.finish();\n\n    let normalized = (hash as f64) / (u64::MAX as f64);\n    if normalized < treatment_weight {\n        Group::Treatment\n    } else {\n        Group::Control\n    }\n}\n\n#[cfg(test)]\nmod tests {\n    use super::*;\n\n    #[test]\n    fn test_deterministic() {\n        let g1 = assign_group("user_42", "button_color_v2", 0.5);\n        let g2 = assign_group("user_42", "button_color_v2", 0.5);\n        assert_eq!(g1, g2);\n    }\n}\n

Dieser Code garantiert, dass derselbe Benutzer für ein bestimmtes Experiment immer in derselben Gruppe ist. Das treatment_weight ist der Anteil des Traffics, der in die Testgruppe geht (z. B. 0,1 = 10%).

Schritt 2. Speicher: Cache oder Datenbank?

Für stark ausgelastete Projekte ist es riskant, Zuweisungen im Speicher zu speichern. Wenn der Server ausfällt, verliert der Benutzer seine Gruppe. Besser ist die Verwendung von Redis oder SQLite. Der Einfachheit halber zeigen wir jedoch einen In-Memory-Cache mit TTL.

use std::collections::HashMap;\nuse std::time::{Duration, Instant};\n\nstruct AssignmentCache {\n    store: HashMap<String, (Group, Instant)>,\n    ttl: Duration,\n}\n\nimpl AssignmentCache {\n    fn new(ttl_secs: u64) -> Self {\n        Self {\n            store: HashMap::new(),\n            ttl: Duration::from_secs(ttl_secs),\n        }\n    }\n\n    fn get(&mut self, key: &str) -> Option<Group> {\n        if let Some((group, time)) = self.store.get(key) {\n            if time.elapsed() < self.ttl {\n                return Some(*group);\n            }\n        }\n        None\n    }\n\n    fn set(&mut self, key: String, group: Group) {\n        self.store.insert(key, (group, Instant::now()));\n    }\n}\n

Ersetzen Sie in einem echten Projekt HashMap durch dashmap oder Redis – das bietet Threadsicherheit und Persistenz.

Integration mit