तपाईंले background jobs र queues कसरी हेर्नुहुन्छ?

Question

Accepted Answer

**Background jobs** (HTTP response लाई block गर्नु हुँदैन ऐसो काम) को लागि, NestJS ले **BullMQ** (एक Redis-backed queue) सँग `@nestjs/bullmq` मार्फत integrate गर्छ। तपाईंले queue मा jobs थप गर्नुहुन्छ र तिनलाई अलग workers मा asynchronously process गर्नुहुन्छ — requests को गति राखिरहन्छ र भारी वा deferred काम को विश्वसनीयता संग हेर्नुहुन्छ।

## Queues को समस्या समाधान गर्छ

```text
Some work is too slow or shouldn't block the request:
  ✗ sending emails, processing images/video, generating reports, calling slow APIs
  → doing it inline makes the user wait and risks timeouts/failures
  ✓ QUEUE the work → respond immediately → a worker processes it in the background
```

## Queue setup गर्दै

```ts
@Module({
  imports: [
    BullModule.forRoot({ connection: { host: "localhost", port: 6379 } }),  // Redis
    BullModule.registerQueue({ name: "email" }),                            // a named queue
  ],
})
export class AppModule {}
```

## Queue मा jobs थप गर्दै (the producer)

```ts
@Injectable()
export class NotificationService {
  constructor(@InjectQueue("email") private emailQueue: Queue) {}

async register(user: User) {
    await this.saveUser(user);
    // queue the email INSTEAD of sending it inline → respond to the user immediately
    await this.emailQueue.add("welcome", { userId: user.id }, {
      attempts: 3,                          // retry up to 3 times on failure
      backoff: { type: "exponential", delay: 5000 },
      delay: 60000,                          // optionally delay the job
    });
  }
}
```

Producer ले job थप गर्छ (retries, backoff, delay जस्ता options सँग) र तुरुन्त फर्काउँछ — user ले email पठाउन का लागि प्रतीक्षा गर्दैन।

## Jobs process गर्दै (the worker/consumer)

```ts
@Processor("email")
export class EmailProcessor extends WorkerHost {
  async process(job: Job) {
    switch (job.name) {
      case "welcome":
        await this.sendWelcomeEmail(job.data.userId);   // the actual work, in the background
        break;
    }
  }
}
```

एक `@Processor` worker ले queue बाट jobs consume गर्छ र actual काम asynchronously गर्छ — request/response cycle बाट अलग (र अलग process मा पनि चल्न सक्छ)।

## Queues ले के प्रदान गर्छ

```text
✓ Async processing — offload slow work, respond to users instantly
✓ Retries & backoff — failed jobs retry automatically (reliability)
✓ Delayed/scheduled jobs — run work later or on a schedule (repeatable jobs)
✓ Rate limiting & concurrency control — bound how fast/many jobs run
✓ Persistence (via Redis) — jobs survive restarts; not lost if the app crashes
✓ Decoupling — producers and workers scale independently
```

## किन यो महत्त्वपूर्ण छ

Background job processing with queues मजबुत, responsive, scalable back-ends बनाउनको लागि आवश्यक छ — र NestJS को BullMQ integration बुझ्नु senior-level ज्ञान हो।

मुख्य मूल्य HTTP response लाई block गर्नु हुँदैन ऐसो काम offload गर्नु हो: emails पठाउनु, images/video process गर्नु, reports generate गर्नु, data sync गर्नु, वा slow external services को call गर्नु।

ऐसो काम inline गर्दा users लाई प्रतीक्षा गर्न दिन्छ, request timeouts को जोखिम राख्छ, र failure भएमा काम हराउँछ — जबकि **queuing** गरेमा तपाईंले तुरुन्त respond गर्न सक्नुहुन्छ जब background **worker** ले यो विश्वसनीयता संग process गर्छ।

Async offloading भन्दा पनि परे, queues ले critical production features प्रदान गर्छ: **automatic retries with backoff** (transient failures विरुद्ध resilience), **delayed र scheduled jobs**, **concurrency/rate-limiting control**, र **persistence** (Redis-backed jobs crashes/restarts मा survive गर्छ, त्यसैले काम हरउँदैन)।

तिनले **decouple** पनि गर्छ producers बाट consumers, independent scaling गर्न अनुमति दिन्छ।

Queues setup गर्न, appropriate options (retries, delays) सँग jobs थप गर्न, र workers मा तिनलाई process गर्न जान्नु real applications को लागि valuable छ जो भारी वा deferred काम को gracefully handle गर्छ।

यो एक common, महत्त्वपूर्ण pattern छ production NestJS systems मा र mature understanding को प्रतिफलन छ responsive, reliable back-ends बनाउनको लागि जो simple request-response handling भन्दा परे जान्छ।