Microservice transports: TCP, Redis, NATS, Kafka

A microservice is an app on a transporter, not HTTP

A Nest microservice is the same AppModule you already write, bootstrapped to listen on a transporter instead of an HTTP server. You call createMicroservice with a transport and options; the transporter is swappable, and your controllers’ handlers stay byte-for-byte the same when you move from TCP to Kafka.

import { NestFactory } from '@nestjs/core';
import { Transport, MicroserviceOptions } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
    transport: Transport.TCP, // swap to REDIS / NATS / RMQ / KAFKA, handlers unchanged
    options: { host: '0.0.0.0', port: 3001 },
  });
  await app.listen();
}
bootstrap();

Handlers come in two flavours, and the distinction is the most important idea in the lesson. @MessagePattern(pattern) is request–response: the handler’s return value (or Observable) is serialized back to the caller, and the transporter correlates the reply to the request with a correlation id. @EventPattern(event) is fire-and-forget: it reacts to something that happened and returns nothing — there is no reply channel at all.

import { Controller } from '@nestjs/common';
import { MessagePattern, EventPattern, Payload } from '@nestjs/microservices';

@Controller()
export class OrdersController {
  // request–response: caller is waiting for this return value
  @MessagePattern({ cmd: 'order.total' })
  total(@Payload() ids: number[]): number {
    return ids.reduce((sum, id) => sum + priceOf(id), 0);
  }

  // fire-and-forget: "this happened"; nobody is waiting for a reply
  @EventPattern('order.placed')
  async onOrderPlaced(@Payload() order: OrderDto): Promise<void> {
    await this.billing.charge(order); // no return value is sent anywhere
  }
}

On the caller side, ClientProxy mirrors the split: send() for @MessagePattern, emit() for @EventPattern. send() returns a cold Observable — nothing is sent until you subscribe, and the stream emits the reply — so it is for “I need an answer”. emit() publishes the event and does not wait for one — it is for “this happened, react if you care”.

import { Injectable, Inject } from '@nestjs/common';
import { ClientProxy } from '@nestjs/microservices';
import { firstValueFrom } from 'rxjs';

@Injectable()
export class OrdersService {
  constructor(@Inject('ORDERS') private readonly client: ClientProxy) {}

  // send: returns an Observable of the reply; await it for the value
  total(ids: number[]) {
    return firstValueFrom(this.client.send<number>({ cmd: 'order.total' }, ids));
  }

  // emit: publish and move on; no reply is expected
  placed(order: OrderDto) {
    this.client.emit('order.placed', order); // fire-and-forget
  }
}

Choosing a transporter: it is a choice about delivery

Every transporter speaks the same handler API, so the decision is never about syntax — it is about delivery semantics: does the broker persist the message, can a recovered consumer replay it, is ordering guaranteed, how much throughput does it sustain. TCP and Redis pub/sub are simple and fast but lossy; RabbitMQ and Kafka are durable but make you pay for it with idempotency. When you see a “lost events” incident report, this table is where the postmortem starts.

Two facts from that table carry the senior weight. First, at-least-once (RabbitMQ, Kafka) means redelivery, which means your consumer can run twice on the same message — so it must be idempotent or you double-charge a card. Second, Kafka orders messages only within a partition, not across the topic: events for one orderId stay ordered only if they hash to the same partition (key by orderId), and a consumer group spreads partitions across instances for parallelism while preserving per-partition order. Kafka request–response also exists but is heavier — the client must subscribeToResponseOf(topic) so replies land on a dedicated reply topic, matched back by correlation id.

// Kafka microservice: a broker list and a consumer group
const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
  transport: Transport.KAFKA,
  options: {
    client: { brokers: ['localhost:9092'] },
    consumer: { groupId: 'billing-consumer' }, // group => partitions split across pods
  },
});

Hybrid apps: HTTP and a transporter at once

You rarely throw away HTTP. A hybrid application is a normal HTTP app that also listens as a microservice: you connectMicroservice one or more transporters, then startAllMicroservices() before listen(). The same process serves REST and reacts to broker events.

const app = await NestFactory.create(AppModule);
app.connectMicroservice<MicroserviceOptions>({
  transport: Transport.KAFKA,
  options: { client: { brokers: ['localhost:9092'] }, consumer: { groupId: 'orders' } },
});
await app.startAllMicroservices(); // begin consuming events
await app.listen(3000);            // and keep serving HTTP