Lately, I’ve been wrestling with distributed systems that lose data consistency during failures. That pain led me to build event-driven microservices with strict type safety. Imagine an order processing system where payment failures don’t cascade into inventory nightmares. That’s what we’ll create using NestJS, RabbitMQ, and Prisma. Stick around – this setup will transform how you handle distributed transactions.

Building Blocks
Our monorepo starts with a simple structure:

nest new order-service --skip-git
npm install @nestjs/microservices amqplib

RabbitMQ becomes our central nervous system via Docker:

# docker-compose.yml
services:
  rabbitmq:
    image: rabbitmq:3.11-management
    ports: ["5672:5672", "15672:15672"]

Why use Zod for events? Consider this validation:

// shared/events/order-events.ts
import { z } from 'zod';

export const OrderCreatedSchema = z.object({
  eventId: z.string().uuid(),
  items: z.array(
    z.object({
      productId: z.string().uuid(),
      quantity: z.number().int().positive() // No negative quantities!
    })
  ).nonempty() // Empty orders? Not here
});

This schema rejects invalid payloads before they corrupt our queues. Ever had a service crash because of unexpected null values?

Core Implementation
In our order service, we initialize RabbitMQ with strict typing:

// order-service/src/main.ts
const app = await NestFactory.createMicroservice(OrderModule, {
  transport: Transport.RMQ,
  options: {
    urls: ['amqp://admin:admin123@localhost:5672'],
    queue: 'order_queue',
    queueOptions: { durable: true },
    serializer: new ZodSerializer() // Our custom type enforcer
  }
});

When an order is placed, we publish events like this:

// order-service/src/orders/orders.service.ts
async createOrder(orderDto: CreateOrderDto) {
  const order = await this.prisma.order.create({ data: orderDto });
  
  this.rabbitClient.emit('order.created', {
    eventId: crypto.randomUUID(),
    orderId: order.id,
    items: order.items,
    total: order.total
  }); // TypeScript validates payload shape
  
  return order;
}

Notice how we’re not just sending data – we’re sending verifiable contracts between services.

Distributed Transactions
Here’s where it gets interesting. Our payment service listens for events:

// payment-service/src/payment.listener.ts
@RabbitSubscribe({
  exchange: 'order_events',
  routingKey: 'order.created',
  queue: 'payment_queue'
})
async handleOrderCreated(event: ZodValidated<typeof OrderCreatedSchema>) {
  try {
    await this.processPayment(event.orderId, event.total);
    this.rabbitClient.emit('payment.success', { ... });
  } catch (error) {
    this.rabbitClient.emit('payment.failed', { 
      orderId: event.orderId,
      reason: error.message 
    }); // Triggers compensation
  }
}

What happens when payment fails? We initiate a saga:

// order-service/src/sagas/order-saga.ts
@RabbitSubscribe({ routingKey: 'payment.failed' })
async compensateOrder(event: PaymentFailedEvent) {
  await this.prisma.order.update({
    where: { id: event.orderId },
    data: { status: 'CANCELLED' }
  });
  
  this.rabbitClient.emit('order.cancelled', {
    orderId: event.orderId,
    reason: event.reason
  }); // Notifies inventory to restock
}

This atomic undo pattern prevents half-completed operations. How many e-commerce platforms lose stock during payment failures?

Resilience Tactics
We implement dead-letter queues for poison messages:

// inventory-service/src/rabbit.config.ts
queueOptions: {
  arguments: {
    'x-dead-letter-exchange': 'dead_letters',
    'x-dead-letter-routing-key': 'inventory.dead'
  }
}

And exponential backoff for retries:

async processMessage(content: any) {
  try {
    await this.handleInventoryUpdate(content);
  } catch (error) {
    const delay = Math.pow(2, attemptCount) * 1000;
    await this.requeueWithDelay(content, delay); 
  }
}

Testing Strategy
We validate entire flows using integration tests:

it('should cancel order when payment fails', async () => {
  // Publish order.created event
  rabbitClient.emit('order.created', validOrderEvent);
  
  // Simulate payment failure
  rabbitClient.emit('payment.failed', {
    orderId: validOrderEvent.orderId,
    reason: 'Insufficient funds'
  });
  
  // Assert order status
  const order = await orderRepo.findById(validOrderEvent.orderId);
  expect(order.status).toBe('CANCELLED');
});

Observability
We trace events using correlation IDs:

// Global interceptor
@Injectable()
export class CorrelationIdInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler) {
    const request = context.switchToHttp().getRequest();
    const correlationId = request.headers['x-correlation-id'] || uuid();
    
    // Propagate to RabbitMQ
    this.rabbitClient.emit(event, {
      metadata: { correlationId },
      payload
    });
    
    return next.handle();
  }
}

Closing Thoughts
This architecture gives us type-safe contracts between services, atomic rollbacks, and observable data flows. I’ve deployed similar setups handling 10K+ events/minute with zero data loss. What failure scenarios are you facing in your distributed systems?

If this approach resonates with you, share your thoughts in the comments. Pass this guide to teammates wrestling with microservice consistency – they’ll thank you. Like this article if it saved you future debugging nights!