I’ve been thinking a lot about how modern applications scale and stay responsive under heavy loads. The answer, I’ve found, often lies in event-driven microservices. When services communicate asynchronously rather than through direct calls, they become more resilient, scalable, and easier to maintain. That’s why I want to walk you through building a complete event-driven system using NestJS, RabbitMQ, and MongoDB.

Let’s start by setting up our project structure. I prefer using a monorepo with a shared package for common types and utilities. This keeps our services consistent and reduces duplication. Here’s how you can structure it:

mkdir event-driven-microservices
cd event-driven-microservices
npm init -y
mkdir -p packages/shared packages/user-service packages/order-service packages/notification-service

Now, let’s define our event schemas in the shared package. Clear, versioned events are the foundation of a reliable system. Here’s an example:

// packages/shared/src/events/base-event.ts
export interface BaseEvent {
  id: string;
  type: string;
  timestamp: Date;
  version: number;
}

export interface UserCreatedEvent extends BaseEvent {
  type: 'user.created';
  data: {
    email: string;
    firstName: string;
    lastName: string;
  };
}

Why is versioning important? It allows us to evolve our events without breaking existing services.

Next, we’ll set up RabbitMQ using Docker. This message broker will handle all communication between our services. Here’s a simple docker-compose.yml to get started:

services:
  rabbitmq:
    image: rabbitmq:3.12-management
    ports:
      - "5672:5672"
      - "15672:15672"
    environment:
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_PASS: password

With RabbitMQ running, let’s build our first service: the User Service. In NestJS, we can use the @nestjs/microservices package to simplify RabbitMQ integration. Here’s a snippet for publishing an event when a user is created:

// user-service/src/user/user.service.ts
@Injectable()
export class UserService {
  constructor(private readonly rabbitMQClient: ClientProxy) {}

  async createUser(createUserDto: CreateUserDto) {
    const user = await this.userModel.create(createUserDto);
    const event: UserCreatedEvent = {
      id: uuidv4(),
      type: 'user.created',
      timestamp: new Date(),
      version: 1,
      data: user
    };
    this.rabbitMQClient.emit('user.created', event);
    return user;
  }
}

How do we ensure events are processed correctly even if a service is temporarily down? That’s where RabbitMQ’s persistence and acknowledgments come in.

Now, let’s look at the Order Service consuming these events. We’ll set up a message handler that listens for user events and updates its local data:

// order-service/src/events/user-events.handler.ts
@Controller()
export class UserEventsHandler {
  @EventPattern('user.created')
  async handleUserCreated(event: UserCreatedEvent) {
    await this.orderModel.createCustomerProfile({
      userId: event.data.id,
      email: event.data.email,
      firstName: event.data.firstName,
      lastName: event.data.lastName
    });
  }
}

But what happens when something goes wrong? Error handling is critical. We can use dead letter exchanges (DLX) in RabbitMQ to manage failed messages:

// Configure a queue with DLX
const queueOptions = {
  durable: true,
  deadLetterExchange: 'domain.events.dlx',
  messageTtl: 60000
};

MongoDB plays a key role in storing both our application state and event logs. Using event sourcing, we can rebuild state by replaying events—a powerful pattern for debugging and recovery.

Monitoring is another area we can’t overlook. I integrate OpenTelemetry to trace events across services. This helps pinpoint bottlenecks and understand event flows:

// Example of adding a trace to an event
import { trace } from '@opentelemetry/api';
const tracer = trace.getTracer('user-service');
tracer.startActiveSpan('publish.user.created', span => {
  this.rabbitMQClient.emit('user.created', event);
  span.end();
});

Testing event-driven systems requires simulating real-world conditions. I use Jest with custom utilities to mock RabbitMQ and verify event interactions:

// Example test for user creation event
it('should publish user.created event', async () => {
  const emitSpy = jest.spyOn(rabbitMQClient, 'emit');
  await userService.createUser(testUserDto);
  expect(emitSpy).toHaveBeenCalledWith('user.created', expect.any(Object));
});

As we wrap up, remember that event-driven architecture isn’t just a technical choice—it’s a way to build systems that grow with your needs. I encourage you to try these patterns, adapt them to your context, and see the difference they make.

If you found this guide helpful, feel free to like, share, or comment with your experiences. I’d love to hear how you’re using event-driven microservices in your projects!