Node.js & NestJS Backend Engineer
I build backends that hold up under real load — NestJS and Node.js services with clean module boundaries, multi-tenant data isolation, queue-driven background work, and APIs that are a pleasure to integrate. Postgres, Redis, BullMQ.
What it is
Node.js is the JavaScript runtime for servers; NestJS is a structured, TypeScript-first framework on top of it that brings modules, dependency injection, and clear architecture to Node backends — well-suited to APIs that need to scale in complexity, not just traffic.
Why it matters
Backends fail at the seams: tenant isolation, idempotent webhooks, background jobs, and connection management. NestJS's structure makes those seams explicit, which is exactly what you want when a five-person team is shipping nine products.
My experience
I've architected multi-tenant systems with granular RBAC, built payment-analytics pipelines over Trust Payments / Norbr webhook data, integrated OpenAI APIs to cut support tickets 30%, and run background work with BullMQ on Redis. I led a Heroku→OVHcloud migration and a 120+ finding production-readiness security program.
Projects
Architecture decisions & trade-offs
Isolation enforced in the data layer (row-level security or strictly scoped queries), tenant context resolved once and threaded through — never reconstructed ad hoc.
Anything slow or external (emails, PDFs, webhooks, AI calls) goes to a queue (BullMQ/Redis) with retries and idempotency, not the request path.
Treat every webhook as at-least-once: verify signatures, dedupe by event id, make handlers idempotent.
- Doing slow work in the request/response cycle instead of a queue.
- Non-idempotent webhook handlers that double-charge or double-send on retries.
- Exhausting the Postgres connection pool by not pooling correctly under load.
- Explicit module boundaries and dependency injection (NestJS).
- Queue-driven architecture for anything slow or external.
- Idempotency keys + signature verification on every webhook.
- Structured logging and rate limiting from day one.
FAQ
When should I choose NestJS over plain Express?
When the backend will grow in complexity and be worked on by a team. NestJS's modules, DI, and conventions keep a growing codebase navigable; Express is fine for small, simple services.
How do you handle Stripe/PSP webhooks reliably?
Verify the signature, dedupe by event id, and make the handler idempotent so retries are safe — then do the slow work in a queue, not inline.
Key takeaways
- Backend reliability lives at the seams: tenancy, webhooks, jobs, pooling.
- Queue everything slow or external; keep the request path fast.
- Idempotency is non-negotiable for payments and webhooks.