Scheduling Spring Batch Jobs with Quartz (Clustered)

Spring's @Scheduled works for single-instance deployments, but in a cluster every replica fires the trigger — you need a scheduler with distributed locking.

Quartz clustered mode is the standard answer:

• JDBC-backed JobStore with org.quartz.jobStore.isClustered=true
• All nodes share the same Quartz schema
• One node grabs the trigger row lock and runs the job
• Bridge to Spring Batch via QuartzJobBean calling JobLauncher.run(job, params)
• Always include a unique parameter (timestamp or RunIdIncrementer) so each fire creates a new JobInstance

ShedLock is the lightweight alternative:

• @Scheduled plus @SchedulerLock(name, lockAtMostFor, lockAtLeastFor)
• Backed by a LockProvider (JDBC, Redis, ZooKeeper)
• Only one node holds the named lock at a time
• Use when you want simplicity over Quartz's rich features

Kubernetes CronJob is the operational alternative:

• K8s schedules a fresh Pod at each tick
• Pod runs the Boot app, runs the batch job, exits
• No scheduler inside the application
• Use when you're K8s-native and want operational separation

Production practices:

• Apply Quartz DDL via Flyway, not initialize-schema
• Set explicit misfire policies — fire-and-proceed for daily reports, do-nothing for high-frequency syncs
• Size the Quartz thread pool to peak job concurrency
• Set requestRecovery(true) on JobDetails so node crashes don't orphan work
• Make Batch jobs idempotent — recovery may re-run them
• Emit Micrometer metrics for misfires, durations, in-flight jobs

Anti-patterns to call out:

• @Scheduled in a multi-replica deployment
• Same JobParameters every run (JobInstanceAlreadyCompleteException)
• initialize-schema: always in production
• Long-running jobs starving the Quartz thread pool

In an interview I'd emphasize that the choice is operational, not technical — Quartz, ShedLock, and K8s CronJob all work; pick by team expertise and infrastructure context.