Stratégies de Retry Camunda — Analyse Approfondie (Éviter les Incidents en Production)
Dans l’automatisation des workflows, les erreurs ne sont pas des exceptions — elles sont normales.
Les appels réseau échouent
Les bases de données se verrouillent
Les systèmes externes expirent
Un processus Camunda bien conçu doit anticiper l’échec et récupérer automatiquement.
Les stratégies de retry sont donc l’un des concepts les plus importants pour un système BPM en production.
Pourquoi les retries sont essentiels
Sans retry :
Les processus échouent définitivement
Les utilisateurs redémarrent manuellement
Les données deviennent incohérentes
Avec retry :
Les erreurs temporaires disparaissent automatiquement
Le système devient résilient
La charge d’exploitation diminue
Les retries transforment un workflow fragile en système tolérant aux pannes.
Types d’erreurs
| Type | Exemple | Retry |
|---|---|---|
| Technique | timeout réseau | Oui |
| Temporaire | service indisponible | Oui |
| Métier | validation invalide | Non |
| Permanente | données incorrectes | Non |
Règle principale :
On retry les erreurs techniques, jamais les erreurs métier.
Concept de retry dans Camunda
Camunda gère les retries différemment selon la version :
| Camunda 7 | Camunda 8 |
|---|---|
| Retry côté moteur | Retry côté worker |
| Défini dans BPMN | Défini dans le code |
| Piloté par l’engine | Piloté par le client |
Retry dans Camunda 8 (Worker)
Quand un worker échoue :
Il envoie le nombre de retries restants
Le moteur reprogramme la tâche
Un délai est appliqué
Exemple :
client.newFailCommand(job.getKey())
.retries(job.getRetries() - 1)
.errorMessage("Erreur temporaire")
.send();
Stratégie Backoff
Ne jamais retry immédiatement.
Utiliser un délai progressif :
| Tentative | Délai |
|---|---|
| 1 | 5 sec |
| 2 | 30 sec |
| 3 | 2 min |
| 4 | 10 min |
Cela évite la surcharge système.
Patterns de retry
Retry immédiat (à éviter)
Crée une tempête de requêtes
Délai fixe
Simple mais inefficace
Exponential Backoff (recommandé)
Meilleure pratique
BPMN Error vs Retry
| Retry | BPMN Error |
|---|---|
| Problème technique | Logique métier |
| Automatique | Décision métier |
| Infrastructure | Intervention utilisateur |
Exemple :
Timeout API paiement → Retry
Paiement refusé → BPMN Error
Idempotence — Concept critique
Le retry ne doit jamais créer de doublon.
Mauvais :
Créer commande → retry → double commande
Correct :
Vérifier si déjà traité
Dead Letter Jobs
Quand retries = 0 :
Le processus devient incident.
L’équipe doit :
Corriger la cause
Résoudre l’incident
Relancer
Exemple réel
Problème :
API bancaire lente
Solution :
Retry avec backoff exponentiel
Résultat :
80% des incidents supprimés automatiquement
Recommandations
1. Toujours distinguer erreur métier vs technique
Erreur d’architecture fréquente
2. Utiliser exponential backoff
Évite panne en cascade
3. Rendre les workers idempotents
Obligatoire en finance
4. Surveiller les retries
Pic = problème externe
5. Jamais de retry infini
Limiter tentatives
6. Logger la cause
Indispensable pour debug
7. Alerter seulement après échec final
Évite alert fatigue
Conclusion
La stratégie de retry n’est pas un détail de configuration —
c’est un mécanisme central de fiabilité.
Un bon design de retry rend le système auto-réparant.
Un mauvais design provoque des pannes.
📚 Lectures recommandées
Pour plus d’articles techniques :
👉 https://shikhanirankari.blogspot.com/search/label/French
Articles sur :
Comments
Post a Comment