Souls

Reference data (animal types, breeds, colors, tag types) needed fast validation on every animal write without a DB query per field.

Cache all active reference IDs into Redis sets and hashes at startup with in-memory fallback Sets/Maps. Validation is a single Redis SISMEMBER or HGET call.

Cache can drift after admin updates. A refreshAllCache() method exists to force a reload, but automated invalidation is not wired up — a stale write window exists until manual or restart-triggered refresh.

Notification delivery needs retry logic, scheduling, quiet-hours delay, and delivery tracking without blocking the HTTP request.

Use BullMQ with exponential backoff (5 attempts, 3s base delay) per delivery record. Delivery records hold idempotency keys and processing leases. A 60-second reconcile loop re-enqueues stuck deliveries.

Requires Redis in production. The code enforces this: Redis unavailability throws a FATAL error in production but degrades gracefully in development, disabling queue features.

Four frontends need CORS access to a single API while preventing arbitrary origins.

CORS is configured with an explicit allowlist of four Vercel deployment URLs plus four LAN IPs for local development. Credentials are enabled.

New frontend deployments require a backend code change to add the origin. There is no runtime config or environment-variable-driven allowlist.

Redis may not be available in development environments, but the notification and animal-create queues depend on it.

RedisConnectionService uses lazyConnect and catches the initial connection failure. isAvailable is set to false and propagated to all queue/worker services via guard checks in onModuleInit. Features degrade silently in dev; in production a FATAL error is thrown.

The app boots and serves all non-queue endpoints in dev without Redis. Queue-dependent features are simply no-ops. In production, a missing Redis blocks startup rather than causing silent data loss.

Animal creation involves multiple file uploads (photo + gallery + documents), storage to CDN, and several DB writes that must be atomic or rolled back.

An animal-create BullMQ queue job carries pre-uploaded filenames alongside the full DTO. The worker handles DB writes with the uploaded CDN URLs. Temp files on disk are deleted in a finally block regardless of upload success or failure.

File uploads are separated from DB writes; upload failures clean up temp files without leaving orphaned DB records.

Notification quiet-hours logic must handle overnight ranges (e.g. 22:00–06:00) and respect per-notification priority (CRITICAL bypasses quiet hours).

The preference resolver calculates minutesSinceMidnight in the system timezone, checks isOvernight = start > end, and computes the delay-until datetime. CRITICAL priority notifications skip the quiet-hours check entirely.

Quiet-hours logic is self-contained in a single service and handles both same-day and overnight window ranges.