Vous exploitez six instances d'un service et un travail nocturne doit tourner exactement une fois. Comment organisez-vous ça ?

Ne comptez pas sur un cron local exécuté par chaque instance. Utilisez un verrou de leader, comme une ligne ou une clé acquise avec un bail et une durée de vie, pour que seul le détenteur exécute le travail, ou déléguez la planification à un cron au niveau plateforme qui met en file un seul travail qu'un worker viendra prendre. Dans les deux cas, rendez le travail idempotent et observable, parce qu'un bail peut expirer en pleine exécution et provoquer un chevauchement.

La version naïve tourne six fois, et la version où une instance spéciale est désignée cesse de marcher le jour où cette instance est en mauvaise santé. Donc soit j'utilise un verrou, soit je sors complètement la planification de l'application. Avec un verrou, chaque instance tente d'acquérir un bail à l'heure prévue, typiquement une insertion ou une mise à jour conditionnelle sur une table de travaux avec une expiration, et seul le gagnant s'exécute en renouvelant le bail pendant qu'il travaille. La subtilité, c'est qu'un bail peut expirer pendant une longue exécution, et alors une seconde instance démarre, donc le travail doit quand même pouvoir tourner deux fois sans risque. Ma préférence à toute échelle, c'est la seconde approche : une planification au niveau plateforme qui met en file un seul message, et des workers ordinaires le consomment. Ça donne gratuitement les reprises, la visibilité et l'historique, et le code applicatif devient un simple gestionnaire. Dans tous les cas, j'enregistre les heures de début et de fin et j'alerte quand un travail ne s'est pas terminé dans sa fenêtre attendue, parce qu'un travail qui cesse discrètement de tourner est le genre d'échec que les gens remarquent des semaines plus tard.