Hoe coördineer je een cronjob over meerdere NestJS-nodes?

Question

IT Interview Practice · Accepted Answer

Definieer eerst wat “slechts één node voert de cronjob uit” betekent. **Gelijktijdige uitvoering voorkomen en een herhaald bedrijfseffect voorkomen zijn verschillende eisen.** Een gedeelde scheduler coördineert de uitvoering; de bewerking zelf moet veilig blijven na een crash en retry.

Denk aan een dagelijkse factuurtaak op drie NestJS-nodes. De geplande taak moet draaien zonder een extra factuur te maken wanneer een worker herstart.

## 1. Begrijp waarom alle nodes beginnen

Elke applicatie-instantie registreert een eigen croncallback. Op het geplande tijdstip kunnen ze onafhankelijk starten:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

Een lokale isRunning-vlag bestaat maar in één proces. NestJS waitForCompletion kan overlappende callbacks op die instantie voorkomen, maar coördineert andere nodes niet. Dezelfde vlag op drie nodes levert nog steeds drie afzonderlijke beslissingen op. [NestJS-scheduling](https://docs.nestjs.com/techniques/task-scheduling).

We hebben dus een gedeelde plek nodig die bepaalt welk werk bestaat en wie het mag verwerken.

## 2. Kies het coördinatiemodel

| Situatie | Te beoordelen optie | Resterende verantwoordelijkheid |
| --- | --- | --- |
| Het platform biedt al geplande taken | Plan buiten de webinstanties | Configureer overlap, herstel en gemiste uitvoeringen. |
| Het team beheert al BullMQ | Gedeelde Job Scheduler en eigen queue | Configureer gedeelde concurrency en veilige retries. |
| De bestaande taak moet op applicatienodes blijven | Gedeeld slot of lease | Behandel eigendom, verloop en verouderde workers correct. |

Als Redis en BullMQ al bestaan, is voor de facturen een gedeelde scheduler met een stabiele scheduler-ID praktisch. Scheid het schema van de workers, zodat extra webnodes geen onafhankelijke schema’s creëren.

Stel in een ondersteunde BullMQ-versie de globale concurrency van de eigen queue in op één. Dit begrenst actieve jobs over alle workers; lokale concurrency van één per worker laat nog steeds meerdere workers verschillende jobs uitvoeren. [Globale concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Bepaal wat gebeurt als het werk van gisteren nog draait: wachten, overslaan of uitvoeringen combineren. Leg de tijdzone vast en bepaal of gemiste bedrijfsdatums na uitval moeten worden ingehaald.

## 3. Bescherm de factuur, niet alleen de job

Stel dat een worker een factuur maakt en crasht voordat hij de job als voltooid registreert. Herstel kan de job opnieuw uitvoeren terwijl de factuur al bestaat.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

Gebruik een stabiele bedrijfssleutel, bijvoorbeeld klant plus factuurperiode. Bij lokaal databasewerk kunnen een unieke constraint en een transactie het maken van de factuur koppelen aan de registratie van de voltooide uitvoering. Een retry vindt dan het bestaande resultaat in plaats van een extra factuur te maken.

Gebruik bij een externe leverancier diens idempotentiesleutel indien ondersteund en reconcilieer onzekere uitkomsten. Een queue-job-ID of bewaard jobrecord alleen garandeert niet permanent dat een bedrijfsactie nooit wordt herhaald. [Idempotente jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Weet wat een slot wel en niet garandeert

Een gedeeld slot moet atomair worden verkregen. Gebruik een eigendomstoken, vervaltijd en vernieuwing; geef alleen vrij als het token nog overeenkomt. Anders kan een oude worker het slot van een nieuwe vrijgeven.

Verloop creëert een extra scenario: een gepauzeerde worker hervat nadat zijn lease is verlopen, terwijl een nieuwe worker al draait. Kritieke schrijfbewerkingen kunnen fencing tokens vereisen: oplopende eigendomsnummers die de bestemming controleert om verouderde workers te weigeren. Alleen een lange timeout instellen neemt dit risico niet weg.

Als coördinatie niet beschikbaar is, bepaal dan of de taak moet wachten in plaats van zonder eigendom te draaien. Voor werk met belangrijke gevolgen is wachten vaak veiliger.

## 5. Controleer de foutscenario’s

Test meerdere nodes, een crash na factuurcreatie, een pauze langer dan de lease, verlies van Redis-connectiviteit en een rolling deployment. Registreer bedrijfsdatum, worker, poging en uitkomst om herhaalde pogingen te onderscheiden van herhaalde effecten.

**Onthoud:** planning coördineren → gedeelde uitvoering begrenzen → bedrijfsactie veilig herhaalbaar maken → herstel testen. “Eén actieve job” bewijst op zichzelf niet precies één bedrijfseffect.

Situatie	Te beoordelen optie	Resterende verantwoordelijkheid
Het platform biedt al geplande taken	Plan buiten de webinstanties	Configureer overlap, herstel en gemiste uitvoeringen.
Het team beheert al BullMQ	Gedeelde Job Scheduler en eigen queue	Configureer gedeelde concurrency en veilige retries.
De bestaande taak moet op applicatienodes blijven	Gedeeld slot of lease	Behandel eigendom, verloop en verouderde workers correct.

1. Begrijp waarom alle nodes beginnen

2. Kies het coördinatiemodel

3. Bescherm de factuur, niet alleen de job

4. Weet wat een slot wel en niet garandeert

5. Controleer de foutscenario’s

Gerelateerde vragen