Architecture événementielle en Rust : exemples concrets et pratique

Quand les événements contrôlent le code : Event-driven en Rust

Imaginez que votre code est un chef d'orchestre. En programmation synchrone classique, le chef décide lui-même quand chaque note doit jouer. Dans l'architecture événementielle, le chef se contente de réagir au fait que les musiciens ont déjà commencé à jouer. Cela semble paradoxal ? Seulement à première vue.

L'architecture événementielle (event-driven) est une approche où le flux d'exécution du programme est déterminé par des événements : clic de souris, réception d'une requête HTTP, fin d'une opération d'entrée-sortie, minuteur. Rust, avec son système de propriété et ses abstractions à coût zéro, est un terrain idéal pour une telle architecture. Surtout si vous venez de Python, où la boucle d'événements (par exemple dans asyncio) fonctionne, mais se heurte souvent au GIL et aux frais généraux du typage dynamique.

Dans cet article, nous ne nous contenterons pas de parler de théorie. Nous écrirons du code réel, analyserons l'architecture événementielle en Rust en utilisant des crates populaires et montrerons comment cela peut accélérer considérablement vos applications.

Pourquoi Rust plutôt que Python pour les événements ?

Python est un excellent langage pour le prototypage. Mais lorsque vous avez besoin d'un traitement d'événements en temps réel avec des milliers de connexions simultanées, Python commence à ralentir. Rust, quant à lui, offre :

\n
• Des abstractions à coût zéro — async/await n'ajoute pas de surcharge si vous n'utilisez pas ses fonctionnalités
\n
• L'absence de ramasse-miettes — pas de pauses soudaines lors du traitement des événements
\n
• Un système de types qui détecte les erreurs à la compilation
\n
• Un vrai parallélisme — pas de multitâche coopératif, mais de véritables threads sans GIL
\n

Si vous écrivez des applications événementielles en Rust, vous obtenez le contrôle sur chaque octet de mémoire et chaque cycle de processeur. Et ce n'est pas du marketing — c'est un fait.

Les bases : Boucle d'événements et traitement des événements

Au cœur de tout système orienté événements se trouve une boucle d'événements (event loop). C'est une boucle infinie qui :

\n
1. Attend l'apparition d'un nouvel événement
\n
2. L'extrait de la file d'attente
\n
3. Le transmet au gestionnaire
\n
4. Répète l'opération
\n

En Rust, la boucle d'événements standard est fournie par la crate tokio. Écrivons un exemple très simple :

use tokio::sync::mpsc;\nuse tokio::time::{sleep, Duration};\n\n#[tokio::main]\nasync fn main() {\n    // Création d'un canal pour transmettre les événements\n    let (tx, mut rx) = mpsc::channel::<String>(32);\n\n    // Producteur : génère les événements\n    tokio::spawn(async move {\n        for i in 0..5 {\n            let event = format!("Événement n°{}", i);\n            tx.send(event).await.unwrap();\n            sleep(Duration::from_millis(500)).await;\n        }\n    });\n\n    // Consommateur : traite les événements\n    while let Some(event) = rx.recv().await {\n        println!("Traité : {}", event);\n        // Votre logique métier peut être ici\n    }\n}

Ce code illustre le modèle de base de la programmation événementielle en Rust : un composant génère des événements, un autre les traite. Le canal mpsc (multi-producteur, mono-consommateur) assure un transfert sécurisé des données entre les tâches.

Exemple avancé : système de traitement de commandes

Complexifions la tâche. Imaginez que nous écrivons le backend d'une boutique en ligne. Lorsqu'une nouvelle commande arrive, il faut :

\n
• Vérifier la disponibilité du produit
\n
• Le réserver
\n
• Envoyer une notification
\n
• Mettre à jour les statistiques
\n

L'approche classique consiste à faire tout cela de manière synchrone. L'approche événementielle consiste à décomposer en événements :

use tokio::sync::broadcast;\nuse tokio::time::sleep;\nuse std::time::Duration;\n\n#[derive(Debug, Clone)]\nenum OrderEvent {\n    NewOrder { id: u32, items: Vec<String>