NestJS architecture, dependency injection, validation, security, errors, testing, persistence, APIs, microservices, and deployment patterns with prioritized rule tiers and companion rule files.
99
100%
Does it follow best practices?
Impact
97%
1.12xAverage score across 2 eval scenarios
Advisory
Suggest reviewing before use
A logistics company sends automated notifications to customers at several stages in their delivery workflow: when an order is confirmed, when it ships, and when it arrives. Currently these notifications are sent synchronously inside the HTTP request handler, causing timeouts when email providers are slow and degrading API response times. On busy days, a single slow mail provider call can cascade into request queue buildup.
The team wants to move notification dispatch to a background job system. Each delivery event should add a job to a queue; a separate worker process consumes those jobs and sends the actual notification (email, SMS, etc.). Jobs that fail due to transient provider errors need automatic retries with exponential backoff. The operations team also wants to monitor queue health as part of the standard readiness checks run by Kubernetes.
The solution should be structured as two NestJS modules: one that publishes events when domain actions happen (e.g., order confirmed, order shipped), and one that contains the worker logic. The modules should not be tightly coupled — the publishing module must not directly import the worker module.
Produce TypeScript source files for the NestJS notification queue system. Include:
main.ts snippet or bootstrap file showing application setupPlace files under src/notifications/. Include a IMPLEMENTATION_NOTES.md describing how the modules are wired together, what retry strategy is used, and how queue health is exposed.
Note: You do not need to implement a real email/SMS provider. Use stub implementations (e.g., console.log) for the actual sending logic. Focus on the NestJS architecture and job queue wiring.
evals
scenario-1
scenario-2
rules