How Red Rock Engineers Reusable Infrastructure: Our npm Packages Built for Production

How Red Rock Engineers Reusable Infrastructure: Our npm Packages Built for Production

Hamid Firoozian (CTO)

|

Published on 2026-02-26

|

Updated on 2026-02-26

|

5 min read

Building backend systems at scale usually means solving the same hard problems again and again: reliable communication, asynchronous processing, retries, observability, and clean integration with existing architecture.

To avoid rewriting these foundations in every project, we packaged our internal patterns into reusable npm libraries.

This post introduces two packages we have deployed, how they are used, what problems they solve, and what they say about our engineering capabilities.

All published packages are available on our npm publisher profile: https://www.npmjs.com/~redrock-technology

noticore: Multi-Channel Notification Core for NestJS

noticore is a notification orchestration library designed for real-world delivery workflows, not just "send one message now".

Package: https://www.npmjs.com/package/noticore

What problem it solves

Teams often struggle with notification systems that become fragmented over time. Separate logic for SMS, email, and push. No unified status tracking. Retry behavior implemented inconsistently. Tight coupling to one database or queue implementation.

noticore addresses this with a single core workflow for notification lifecycle management across channels.

How it is used

You integrate it in a NestJS app, initialize channel configs (FCM, SMS.to, Mailgun), connect your repository layer, and publish events through your queue (Kafka, RabbitMQ, or similar).

From there, application services can create and deliver notifications using a consistent API.

Typical use cases: transactional notifications such as verification and login alerts, product events such as announcements and reminders, and multi-channel fallback delivery strategies.

Technologies and architecture

NestJS-first integration with a TypeScript package and typed APIs. Repository Pattern support for TypeORM, Prisma, or custom implementations. Queue-based async processing via event publisher abstraction. Channel providers: Firebase Admin for push, SMS.to for SMS, Mailgun for email. Reliability features include retries, status tracking, and error handling hooks.

What this shows about our capabilities

Designing extensible platform components. Applying SOLID-friendly boundaries across publisher, repository, and sender abstractions. Building for testability so external providers can be mocked. Shipping production-minded reliability patterns, not just happy-path SDK wrappers.

kafka-mq: Structured Kafka Integration for NestJS

kafka-mq brings an opinionated, modular Kafka developer experience to NestJS, inspired by ergonomic queue libraries.

Package: https://www.npmjs.com/package/kafka-mq

What problem it solves

Kafka integration in many codebases becomes repetitive and error-prone. Boilerplate consumer setup in multiple places. Inconsistent producer and consumer patterns. Hard-to-manage startup wiring. Limited structure for scaling topic handlers across teams.

kafka-mq standardizes this integration layer.

How it is used

Developers register KafkaModule with sync or async config, create handlers with decorators, and send messages through an injected producer service. It also supports producer-only mode for services that publish events without consuming.

Typical use cases: event-driven microservices, domain event publishing from APIs, and scalable consumer groups with clean module boundaries.

Technologies and architecture

NestJS module system with forRoot, forRootAsync, and producer-only setup. Decorator-based consumer registration. KafkaJS under the hood. Dynamic listener wiring for cleaner consumer bootstrapping. TypeScript for strongly typed integration.

What this shows about our capabilities

Translating infrastructure complexity into developer-friendly APIs. Implementing modular architecture patterns for long-term maintainability. Enabling teams to scale event-driven systems with consistent conventions.

Engineering Principles Behind These Packages

Across both packages, our approach is consistent.

Abstraction over vendor lock-in: provider-specific code lives behind interfaces. Separation of concerns: creation, publishing, delivery, and persistence are isolated. Testability by design: third-party integrations are mockable. Scalability readiness: async workflows, retries, and queue-first thinking. Framework-aligned developer experience: native feel inside NestJS modules and the dependency injection ecosystem.

These are not one-off utilities. They are packaged architecture decisions.

Why This Matters for Product Teams

When teams adopt these packages, they get faster implementation of messaging and event workflows, fewer reliability regressions in production, cleaner codebases with consistent patterns, and better onboarding for new engineers through clear module contracts.

Less reinvention, more delivery.

We shipped noticore and kafka-mq to encode our backend engineering standards into reusable building blocks. They represent how we think about system design: practical abstractions, operational reliability, and maintainable architecture.

This is the same standard we bring to every project we work on. If you want a team that engineers for longevity and not just delivery, get in touch with the Red Rock team.