ઘણા NestJS node પર cron jobનું સંકલન કેવી રીતે કરશો?

Question

IT Interview Practice · Accepted Answer

પહેલાં સ્પષ્ટ કરો કે “cronjob માત્ર એક node ચલાવે”નો અર્થ શું છે. **એકસાથે execution અટકાવવું અને વ્યવસાયિક અસર ફરી થતી અટકાવવી અલગ જરૂરિયાતો છે.** Shared scheduler executionનું સંકલન કરે છે; crash પછી retry થાય ત્યારે ક્રિયા પોતે પણ સુરક્ષિત હોવી જોઈએ.

ત્રણ NestJS node પર રોજ invoice બનાવતું કામ ધારો. કામ સમયસર થવું જોઈએ, પરંતુ worker ફરી શરૂ થાય ત્યારે બીજું invoice ન બનવું જોઈએ.

## 1. બધા node કામ કેમ શરૂ કરે છે તે સમજો

દરેક application instance પોતાનો cron callback નોંધે છે. નક્કી સમયે દરેક સ્વતંત્ર રીતે શરૂ થઈ શકે છે:

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

સ્થાનિક isRunning flag એક જ processમાં હોય છે. NestJSનું waitForCompletion એ instanceમાં callbackનું overlap રોકી શકે છે, પરંતુ બીજા nodeનું સંકલન કરતું નથી. ત્રણેય nodeમાં સમાન flag મૂકવાથી પણ ત્રણ અલગ નિર્ણય રહે છે. [NestJS scheduling](https://docs.nestjs.com/techniques/task-scheduling).

એટલે કયું કામ છે અને કોણ તેને ચલાવી શકે તે નક્કી કરવા shared જગ્યા જોઈએ.

## 2. સંકલનની રીત પસંદ કરો

| પરિસ્થિતિ | તપાસવાનો વિકલ્પ | બાકી રહેતી જવાબદારી |
| --- | --- | --- |
| Platform પહેલેથી scheduled jobs આપે છે | Web instancesની બહાર scheduling કરો | Overlap, recovery અને ચૂકી ગયેલા runનું વર્તન ગોઠવો. |
| ટીમ BullMQ પહેલેથી ચલાવે છે | Shared Job Scheduler અને અલગ queue | Shared concurrency અને safe retries ગોઠવો. |
| હાલનું કામ application node પર જ રહેવું જોઈએ | Shared lock અથવા lease | Ownership, expiry અને જૂના workers યોગ્ય રીતે સંભાળો. |

Invoice માટે Redis અને BullMQ પહેલેથી હોય તો stable scheduler ID સાથે shared scheduler વ્યવહારુ વિકલ્પ છે. Schedule અને workers અલગ રાખો, જેથી web node ઉમેરવાથી સ્વતંત્ર schedules ન બને.

સમર્થિત BullMQ versionમાં dedicated queueની global concurrency એક રાખો. તે બધા workersના active jobs મર્યાદિત કરે છે; દરેક workerની local concurrency એક રાખવાથી હજી ઘણા workers જુદા jobs સાથે ચલાવી શકે. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

ગઈકાલનું કામ હજી ચાલતું હોય તો રાહ જોવી, skip કરવું કે occurrences જોડવા તે નક્કી કરો. Time zone અને downtime પછી ચૂકી ગયેલી business dates પૂરી કરવી કે નહીં તે પણ નક્કી કરો.

## 3. માત્ર job નહીં, invoiceને સુરક્ષિત બનાવો

માનો કે worker invoice બનાવે છે અને job પૂર્ણ નોંધતાં પહેલાં crash થાય છે. Recoveryમાં job ફરી ચાલે, ભલે invoice પહેલેથી હોય.

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

Customer અને billing period જેવી stable business key વાપરો. સ્થાનિક databaseના કામમાં unique constraint અને transaction invoiceનું સર્જન અને completed-run record જોડે છે. પછી retry નવું invoice બનાવવાને બદલે જૂનું પરિણામ મેળવે છે.

બાહ્ય provider સમર્થન આપે તો તેની idempotency key વાપરો અને અનિશ્ચિત પરિણામો reconcile કરો. Queue job ID અથવા સાચવેલો job record એકલો વ્યવસાયિક ક્રિયા ક્યારેય ફરી નહીં થાય તેની કાયમી ગેરંટી નથી. [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Lock શું ખાતરી આપે છે અને શું નહીં તે જાણો

Shared lock atomically મેળવવો જોઈએ. Ownership token, expiry અને renewal વાપરો; token હજી મેળ ખાતો હોય ત્યારે જ release કરો. નહીં તો જૂનો worker નવા workerનો lock છોડાવી શકે.

Expiryથી બીજો કિસ્સો બને છે: અટકેલો worker lease પૂરી થયા પછી આગળ વધે, જ્યારે નવો worker પહેલેથી ચાલે છે. Critical writes માટે fencing token જરૂરી હોઈ શકે: વધતા ownership numbers જેને destination તપાસીને જૂના workerને નકારે. માત્ર લાંબો timeout આ જોખમ દૂર કરતો નથી.

સંકલન ઉપલબ્ધ ન હોય તો ownership વગર ચલાવવાને બદલે કામે રાહ જોવી જોઈએ કે નહીં તે નક્કી કરો. મહત્વની અસરવાળા કામ માટે આ ઘણી વાર વધુ સુરક્ષિત છે.

## 5. નિષ્ફળતાના કિસ્સા ચકાસો

ઘણા node, invoice બન્યા પછી crash, leaseથી લાંબો pause, Redis connection ગુમાવવું અને rolling deployment તપાસો. Business date, worker, attempt અને outcome નોંધો જેથી વારંવારના પ્રયાસ અને વારંવારની અસર અલગ ઓળખાય.

**યાદ રાખો:** schedulingનું સંકલન → shared executionની મર્યાદા → retry-safe business action → recoveryની તપાસ. “એક active job” એકલું ચોક્કસ એક business effectનું પ્રમાણ નથી.

પરિસ્થિતિ	તપાસવાનો વિકલ્પ	બાકી રહેતી જવાબદારી
Platform પહેલેથી scheduled jobs આપે છે	Web instancesની બહાર scheduling કરો	Overlap, recovery અને ચૂકી ગયેલા runનું વર્તન ગોઠવો.
ટીમ BullMQ પહેલેથી ચલાવે છે	Shared Job Scheduler અને અલગ queue	Shared concurrency અને safe retries ગોઠવો.
હાલનું કામ application node પર જ રહેવું જોઈએ	Shared lock અથવા lease	Ownership, expiry અને જૂના workers યોગ્ય રીતે સંભાળો.

1. બધા node કામ કેમ શરૂ કરે છે તે સમજો

2. સંકલનની રીત પસંદ કરો

3. માત્ર job નહીં, invoiceને સુરક્ષિત બનાવો

4. Lock શું ખાતરી આપે છે અને શું નહીં તે જાણો

5. નિષ્ફળતાના કિસ્સા ચકાસો

સંબંધિત પ્રશ્નો