একাধিক NestJS node-এ cron job কীভাবে সমন্বয় করবেন?

Question

IT Interview Practice · Accepted Answer

আগে ঠিক করুন “শুধু একটি node cronjob চালাবে” বলতে কী বোঝায়। **একই সময়ে execution আটকানো আর একই ব্যবসায়িক ফল আবার হওয়া আটকানো আলাদা চাহিদা।** Shared scheduler execution সমন্বয় করে; crash ও retry-এর পর operation নিজেকেও নিরাপদ থাকতে হবে।

তিনটি NestJS node-এ চলা দৈনিক invoice job ধরুন। আমরা নির্ধারিত কাজ চালাতে চাই, কিন্তু worker restart হলে আরেকটি invoice তৈরি করতে চাই না।

## 1. সব node কেন কাজ শুরু করে বুঝুন

প্রতিটি application instance নিজস্ব cron callback নিবন্ধন করে। নির্ধারিত সময়ে প্রত্যেকটি স্বাধীনভাবে শুরু করতে পারে:

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

Local isRunning flag শুধু একটি process-এ থাকে। NestJS-এর waitForCompletion সেই instance-এ callback overlap আটকাতে পারে, অন্য node সমন্বয় করে না। তিন node-এ একই flag দিলেও তিনটি আলাদা সিদ্ধান্ত থাকে। [NestJS scheduling](https://docs.nestjs.com/techniques/task-scheduling)।

তাই কোন কাজ আছে এবং কে তা করতে পারবে তা নির্ধারণের shared জায়গা দরকার।

## 2. Coordination model বেছে নিন

| পরিস্থিতি | বিবেচ্য পদ্ধতি | যে দায়িত্ব রয়ে যায় |
| --- | --- | --- |
| Platform আগে থেকেই scheduled job দেয় | Web instance-এর বাইরে scheduling চালান | Overlap, recovery ও বাদ পড়া run-এর আচরণ ঠিক করা। |
| দল আগে থেকেই BullMQ চালায় | Shared Job Scheduler ও dedicated queue | Shared concurrency ও নিরাপদ retry ঠিক করা। |
| বর্তমান task application node-এই রাখতে হবে | Shared lock বা lease | Ownership, expiry ও পুরোনো worker সঠিকভাবে সামলানো। |

Invoice উদাহরণে Redis ও BullMQ থাকলে stable scheduler ID-সহ shared scheduler বাস্তবসম্মত বিকল্প। Schedule ও worker আলাদা রাখুন, যাতে web node যোগ করলে স্বাধীন schedule না তৈরি হয়।

সমর্থিত BullMQ সংস্করণে dedicated queue-র global concurrency এক করুন। এটি সব worker জুড়ে active job সীমিত করে; প্রতিটি worker-এর local concurrency এক হলেও একাধিক worker আলাদা job চালাতে পারে। [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency)।

গতকালের কাজ এখনও চললে অপেক্ষা, skip না occurrence একত্র করা হবে তা ঠিক করুন। Time zone এবং downtime-এর পর বাদ পড়া business date-এর কাজ পূরণ করতে হবে কি না নির্ধারণ করুন।

## 3. শুধু job নয়, invoice সুরক্ষিত করুন

ধরুন worker invoice তৈরি করে job complete লিখে রাখার আগেই crash করল। Recovery আবার job চালাতে পারে যদিও invoice ইতিমধ্যে আছে।

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

Customer ও billing period-এর মতো stable business key নিন। Local database কাজের ক্ষেত্রে unique constraint ও transaction invoice creation-কে completed-run record-এর সঙ্গে যুক্ত করতে পারে। Retry তখন নতুন invoice না বানিয়ে আগের ফল পাবে।

External provider সমর্থন করলে তার idempotency key ব্যবহার করুন এবং অনিশ্চিত ফল মিলিয়ে দেখুন। শুধু queue job ID বা সংরক্ষিত job record কোনো business action কখনও পুনরাবৃত্ত হবে না—এর স্থায়ী নিশ্চয়তা নয়। [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 কাজ করছে। গুরুত্বপূর্ণ write-এ fencing token লাগতে পারে—ক্রমবর্ধমান ownership সংখ্যা, যা destination দেখে পুরোনো worker প্রত্যাখ্যান করে। শুধু দীর্ঘ timeout দিলে এই ঝুঁকি দূর হয় না।

Coordination না থাকলে task ownership ছাড়া চলবে, নাকি অপেক্ষা করবে ঠিক করুন। গুরুত্বপূর্ণ প্রভাবের কাজে অপেক্ষা প্রায়ই নিরাপদ।

## 5. Failure case যাচাই করুন

একাধিক node, invoice তৈরির পর crash, lease-এর চেয়ে দীর্ঘ pause, Redis সংযোগ হারানো এবং rolling deployment পরীক্ষা করুন। Business date, worker, attempt ও outcome লিখুন, যাতে repeated attempt ও repeated effect আলাদা বোঝা যায়।

**মনে রাখুন:** scheduling সমন্বয় → shared execution সীমিত → business action retry-safe → recovery পরীক্ষা। “একটি active job” মানেই ঠিক একটি business effect-এর প্রমাণ নয়।

পরিস্থিতি	বিবেচ্য পদ্ধতি	যে দায়িত্ব রয়ে যায়
Platform আগে থেকেই scheduled job দেয়	Web instance-এর বাইরে scheduling চালান	Overlap, recovery ও বাদ পড়া run-এর আচরণ ঠিক করা।
দল আগে থেকেই BullMQ চালায়	Shared Job Scheduler ও dedicated queue	Shared concurrency ও নিরাপদ retry ঠিক করা।
বর্তমান task application node-এই রাখতে হবে	Shared lock বা lease	Ownership, expiry ও পুরোনো worker সঠিকভাবে সামলানো।

1. সব node কেন কাজ শুরু করে বুঝুন

2. Coordination model বেছে নিন

3. শুধু job নয়, invoice সুরক্ষিত করুন

4. Lock কী নিশ্চিত করে আর কী করে না জানুন

5. Failure case যাচাই করুন

সম্পর্কিত প্রশ্ন