Simplifying db-scheduler Integration in a Microservice Architecture via a wrapper around db-scheduler

[beilCrxmarkets]

🧩 Initial Situation

We operate a microservice architecture with 20+ Spring Boot services, primarily written in Java. For scheduling financing-related jobs reliably and persistently, we chose to integrate the db-scheduler library.

⚠️ Problem

During a POC with one of our services, we realized that while db-scheduler is powerful, it offers more flexibility than we actually need. Features like OneTimeTask, CustomTask, and generic support added complexity to our use case.

Additionally, we had to implement:

• A custom failure handler to meet our operational requirements.
• A TestExecutionListener to avoid side effects during testing.

Copy-pasting these configurations across multiple services was not sustainable.

✅ Solution

We built a wrapper library around db-scheduler to abstract away the complexity and centralize configuration. This gave us several benefits:

• 📍 Centralized Failure Handling
• 🧪 Centralized TestExecutionListener
• 🔄 Easier replacement of the underlying scheduling technology
• 🚪 Simplified and restricted API, tailored to our use case

🔧 Our API Design

We only support two types of tasks: static recurring tasks and dynamic recurring tasks with persistent scheduling.

Static Recurring Tasks

public interface CrxScheduledStatic {
    void execute(CrxExecutionContext executionContext);
    String getTaskName();
    String getCron();
}

Developers implement this interface and expose it as a Spring Bean.

Dynamic Recurring Tasks

public interface CrxScheduledDynamic {
    void execute(String id, CrxExecutionContext executionContext);
    String getTaskName();
}

These are scheduled and managed via:

public interface CrxPersistentTaskScheduler {
    void scheduleTask(CrxScheduledDynamic task, String id, String cronPattern);
    void cancelTask(CrxScheduledDynamic task, String id);
    void start();
    void stop();
}

We scan for beans implementing these interfaces, build the corresponding RecurringTask or RecurringTaskWithPersistentSchedule, and pass them to the SchedulerBuilder.

💬 Discussion Points

• Has anyone else faced similar challenges with db-scheduler’s API complexity?
• Did you choose to build a wrapper library or go with a utility/helper approach?
• If you built a wrapper, how did you design your abstraction?
• If you went with utilities, how did you manage the learning curve and tight coupling to db-scheduler?

We also considered building a utility library that only provides the TestExecutionListener and a preconfigured FailureHandler. However, this would still require developers to learn the db-scheduler API and would tightly couple our services to it.

Looking forward to hearing how others approached this!