I’ve been working with microservices for several years, and I’ve seen firsthand how complex they can become. Recently, I needed to build a scalable e-commerce system that could handle high loads while staying responsive. That’s when I turned to an event-driven architecture using NestJS, RabbitMQ, and MongoDB. Let me show you how to build one from the ground up.

Setting up the foundation is straightforward. We use Docker Compose to run RabbitMQ and MongoDB locally. Notice how the health checks ensure our services start correctly. Have you considered how health checks prevent cascading failures?

# docker-compose.yml
services:
  rabbitmq:
    image: rabbitmq:3-management
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 30s

Our shared events define communication contracts. This UserCreatedEvent structure ensures all services speak the same language. How might inconsistent event schemas break your system?

// shared/events/user.events.ts
export class UserCreatedEvent {
  constructor(
    public readonly userId: string,
    public readonly email: string
  ) {}
}

The User Service demonstrates core patterns. We hash passwords before storage and publish events after database commits. Notice the idempotency check - why is this critical in distributed systems?

// user.service.ts
async createUser(dto: CreateUserDto): Promise<User> {
  const existingUser = await this.userModel.findOne({ 
    email: dto.email 
  });
  if (existingUser) throw new ConflictException('User exists');
  
  const passwordHash = await bcrypt.hash(dto.password, 12);
  const user = await new this.userModel({ ...dto, passwordHash }).save();
  
  this.eventPublisher.publish(new UserCreatedEvent(user.id, user.email));
  return user;
}

For the Order Service, we implement a state machine. The status transitions follow business rules. What happens if an order tries to skip from ‘pending’ directly to ‘shipped’?

// order.service.ts
async updateOrderStatus(orderId: string, newStatus: OrderStatus) {
  const order = await this.orderModel.findById(orderId);
  if (!order) throw new NotFoundException();
  
  const validTransitions = {
    [OrderStatus.PENDING]: [OrderStatus.CONFIRMED, OrderStatus.CANCELLED],
    [OrderStatus.CONFIRMED]: [OrderStatus.SHIPPED]
  };
  
  if (!validTransitions[order.status]?.includes(newStatus)) {
    throw new BadRequestException('Invalid status transition');
  }
  
  const oldStatus = order.status;
  order.status = newStatus;
  await order.save();
  
  this.eventPublisher.publish(
    new OrderStatusChangedEvent(orderId, oldStatus, newStatus)
  );
}

Distributed transactions use the Saga pattern. When creating an order, we coordinate across services. How do we handle partial failures?

// order.saga.ts
async* createOrderSaga(orderData: CreateOrderDto) {
  const order = yield this.ordersService.createDraft(orderData);
  
  try {
    yield this.paymentService.authorizePayment(order.id, order.total);
    yield this.inventoryService.reserveItems(order.items);
    yield this.ordersService.confirmOrder(order.id);
  } catch (error) {
    yield this.ordersService.cancelOrder(order.id);
    yield this.paymentService.cancelAuthorization(order.id);
    throw error;
  }
}

Dead letter queues handle poison messages. This RabbitMQ setup automatically redirects failed messages. What monitoring would you add here?

// notification.module.ts
@Module({
  imports: [
    ClientsModule.register([{
      transport: Transport.RMQ,
      options: {
        urls: ['amqp://localhost:5672'],
        queue: 'notification_queue',
        queueOptions: {
          deadLetterExchange: 'dlx',
          deadLetterRoutingKey: 'notification_queue.dlq'
        }
      }
    }])
  ]
})

Testing requires careful orchestration. We use Dockerized test containers for integration tests. Notice how we reset state between tests. Why is this isolation crucial?

// order.e2e-spec.ts
beforeAll(async () => {
  await rabbitmqContainer.start();
  await mongodbContainer.start();
  
  module = await Test.createTestingModule({
    imports: [OrderModule]
  }).compile();

  app = module.createNestApplication();
  await app.init();
});

afterEach(async () => {
  await orderModel.deleteMany({});
});

For deployment, we add scaling directives. Kubernetes could manage these services, but Docker Compose suffices for development. How would you modify this for production?

# docker-compose.prod.yml
services:
  order-service:
    image: my-registry/order-service:latest
    deploy:
      replicas: 3
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]

I’ve deployed this architecture for clients processing thousands of orders daily. The event-driven approach handles spikes gracefully, and RabbitMQ’s persistence prevents data loss during outages. What challenges might you face scaling this further?

Building this requires patience, but the payoff comes in maintainability and scalability. Each service remains focused, and events create clear boundaries. If you found this helpful, please share it with others facing similar challenges. Have questions or improvements? Let me know in the comments below - I’ll respond to every one.