How to scale more than 1 instance and deal with scheduled task in spring?

I am having a push notifications being send to android and ios application through spring boot every day at 8am Europe/Paris.

If I run multiple instances, the notifications will send multiple times. I am thinking to send every day notifications send on the database, and check them but I am worried it still run multiple times, this is what I am doing:

@Component
public class ScheduledTasks {

    private static final Logger log = LoggerFactory.getLogger(ScheduledTasks.class);

    private static final SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss");

    @Autowired
    private ExpoPushTokenRepository expoPushTokenRepository;

    @Autowired
    private ExpoPushNotificationService expoPushNotificationService;

    @Autowired
    private MessageSource messageSource;

    // TODO: if instances > 1, this will run multiple times, save to database the notifications send and prevent multiple sending.
    @Scheduled(cron = "${cron.promotions.notification}", zone = "Europe/Paris")
    public void sendNewPromotionsNotification() {
        List<ExpoPushToken> expoPushTokenList = expoPushTokenRepository.findAll();
        ArrayList<NotifyRequest> notifyRequestList = new ArrayList<>();
        for (ExpoPushToken expoPushToken : expoPushTokenList) {
            NotifyRequest notifyRequest = new NotifyRequest(
                    expoPushToken.getToken(),
                    "This is a test title",
                    "This is a test subtitle",
                    "This is a test body"
            );
            notifyRequestList.add(notifyRequest);
        }

        expoPushNotificationService.sendPushNotificationToList(notifyRequestList);
        log.info("{} Send push notification to " + expoPushTokenList.size() + " userse", dateFormat.format(new Date()));
    }
}

Does anybody have an idea on how I can prevent that safely?

Quartz would be my mostly database-agnostic solution for the task at hand, but was ruled out, so we are not going to discuss it.

The solution we are going to explore instead makes the following assumptions:

• Postgres >= 9.5 is used (because we are going to use SKIP LOCKED, which was introduced in Postgresl 9.5).
• It is okay to run a native query.

Under this conditions, we can retrieve batches of notifications from multiple instances of the application running through the following query:

SELECT * FROM expo_push_token FOR UPDATE SKIP LOCKED LIMIT 100;

This will retrieve and lock up to 100 entries from the table expo_push_token. If two instances of the application execute this query simultaneously, the received results will be disjoint. 100 is just some sample value. We may want to fine-tune this value for our use case. The locks stay active until the current transaction ends.

After an instance has fetched a batch of notifications, it has to also delete the entries it locked from the table or otherwise mark that this entry has been processed (if we go down this route, we have to modify the query above to filter-out already processed entires) and close the current transaction to release the locks. Each instance of the application would then repeat this query until the query returns zero entries.

There is also an alternative approach: an instance first fetches a batch size of notifications to send, keeps the transaction to the database open (thus continues holding the lock on the database), sends out its notification and then deletes/updates the entries and closes the transactions.

The two solutions have different strengths/weaknesses:

• the first solutions keeps the transaction short. But if the application crashes in the middle of sending out notificatiosn, the part of its batch that was not send out is lost in this run.
• the second solution keeps the transaction open, for possibly a long time. If it crashes in the middle fo sending out notifications, all entries will be unlocked and its batch would be re-processed, possibly resulting in some notifications being sent out twice.

For this solution to work, we also need some kind of job that fills table expo_push_token with the data we need. This job should run beforehand, i.e. its execution should not overlap with the notification sending process.