"🚫 Éviter l’exécution concurrente d’un batch Spring 🌱 embarqué dans un ReplicaSet de plusieurs pods 📦 dans un cluster Kubernetes ☸️"
Ce système exécute un traitement batch quotidien pour détecter et archiver les utilisateurs inactifs depuis plus de 90 jours, à l’aide d’un CronJob Kubernetes.
C'est l'application elle-même qui décide quand exécuter le batch, mais Kubernetes qui :
- Planifie l'exécution à intervalles réguliers (
schedule) - Crée un pod éphémère (temporaire) qui :
- Lance l’application Spring Boot
- Exécute le batch (via
@PostConstructou logique d’init) - Termine (le pod est détruit)
- Aucun risque de concurrence si tu as plusieurs pods ailleurs
- Pas besoin de gérer une logique de planification avec
@Scheduledou des threads - Kubernetes gère tout : planification, isolation, redémarrage si échec, etc.
- Très propre pour les batchs ponctuels ou planifiés
- 📆 Planification automatique via
CronJobKubernetes - 🧼 Archivage des utilisateurs dans une table dédiée
archived_users - 🗑️ Suppression des utilisateurs archivés de la table
users - ⚙️ Spring Batch avec
JdbcCursorItemReaderetCompositeItemWriter - 🐳 Déployable sous forme de pod batch éphémère
Voici l’organisation des fichiers du projet inactive-user-archiver :
flowchart TD
subgraph Kubernetes_Cluster
K8sCronJob[Kubernetes CronJob Planification : 1 fois par jour]
K8sCronJob --> PodBatch[📦 Pod Batch éphémère Résilience : restartPolicy=OnFailure]
Pod1[🟦 Pod App 1]
Pod2[🟦 Pod App 2]
Pod3[🟦 Pod App 3]
end
PodBatch --> SpringBoot[🌱 Spring Boot App]
SpringBoot --> SpringBatch[⚙️ Spring Batch Job]
SpringBatch --> DB1[(📂 Table users)]
SpringBatch --> DB2[(📦 Table archived_users)]
style PodBatch stroke:#f39c12,stroke-width:2px


