Have you ever tried to manage a conversation where everyone is talking at once, constantly asking each other for updates? That’s what traditional, tightly connected microservices can feel like. One service goes down, and the whole chain grinds to a halt. I built too many systems like that before finding a better way. Today, I want to show you how to build services that work together smoothly by reacting to events, not by constantly calling each other. This approach is how modern, resilient applications are built.
Instead of services directly asking each other for data, they broadcast when something important happens. Think of it like a town square announcement. A “User Service” announces, “A new user just signed up!” Any other service that cares about new users—like an “Email Service” or an “Analytics Service”—can listen and act independently. This is the core of event-driven architecture.
So, how do we build this? We need three main tools: a framework to structure our services, a message broker to handle the announcements, and a database to keep a record of everything. That’s where NestJS, RabbitMQ, and MongoDB come together perfectly.
Let’s start by setting the stage. You’ll need Node.js, Docker, and a basic understanding of TypeScript. We’ll create separate services for different parts of our application. A common example is an e-commerce system with separate services for users, orders, and products.
First, we create our project structure and core dependencies. Here’s a snippet from a root package.json to get the shared tools in place.
{
"dependencies": {
"@nestjs/common": "^10.0.0",
"@nestjs/microservices": "^10.0.0",
"amqplib": "^0.10.3",
"mongoose": "^7.5.0",
"rxjs": "^7.8.1"
}
}Why NestJS? It provides a clean, modular structure right out of the box. It handles dependency injection and organizes your code into modules, controllers, and providers. This structure is a lifesaver when your system grows.
Now, for the communication layer. We use RabbitMQ as our message broker—the town square for our events. Services publish messages to exchanges, and other services consume them from queues. This decouples the sender from the receiver completely. The sender doesn’t need to know who is listening.
Here is a basic setup for a NestJS service to connect to RabbitMQ. We create a custom provider for the connection.
// rabbitmq-client.ts
import * as amqp from 'amqplib';
export const rabbitMQProvider = {
provide: 'RABBITMQ_CONNECTION',
useFactory: async () => {
return await amqp.connect('amqp://localhost');
},
};But what are we sending? We need to agree on a common language. We define event types as a shared library that all services understand. This is critical.
// shared/events.ts
export enum EventType {
USER_CREATED = 'user.created',
ORDER_PLACED = 'order.placed'
}
export interface BaseEvent {
type: EventType;
data: any;
timestamp: Date;
}With the connection and events defined, a service can now publish an event. Let’s say a user registers. The User Service would publish a USER_CREATED event.
// user.service.ts - publish method
async publishUserCreated(userDto) {
const channel = await this.connection.createChannel();
await channel.assertExchange('user_events', 'topic', { durable: true });
const event: BaseEvent = {
type: EventType.USER_CREATED,
data: { userId: userDto.id, email: userDto.email },
timestamp: new Date()
};
channel.publish('user_events', 'user.created', Buffer.from(JSON.stringify(event)));
}On the other side, the Email Service needs to listen for this event. In NestJS, we can use a message pattern to handle it.
// email.controller.ts
@Controller()
export class EmailController {
@MessagePattern(EventType.USER_CREATED)
async handleUserCreated(@Payload() event: BaseEvent) {
console.log(`Sending welcome email to: ${event.data.email}`);
// Add your email logic here
}
}Where does MongoDB fit in? It’s our single source of truth for what happened. We store every event in a collection, often called an event store. This gives us a complete history. If a new service joins later, it can read all past events to build its own state. This pattern is called event sourcing.
Here’s a simple Mongoose schema for our event store.
// event.schema.ts
@Schema({ collection: 'events' })
export class EventDocument extends Document {
@Prop({ required: true })
type: string;
@Prop({ type: Object, required: true })
data: any;
@Prop({ required: true, default: Date.now })
timestamp: Date;
@Prop()
aggregateId: string;
}
export const EventSchema = SchemaFactory.createForClass(EventDocument);What happens when things go wrong? This is a vital question. In a distributed system, failures are expected. A service might be down when an event is sent. RabbitMQ queues make messages persistent, so they’ll wait until the service is back up. We also need strategies for retrying failed operations and managing transactions across services, which can involve more advanced patterns.
Testing becomes different too. You’re not just testing function outputs, but verifying that the right events are published and handled. You’ll often run an in-memory RabbitMQ instance and MongoDB for your tests.
Finally, how do you know if the system is healthy? You need good monitoring. Track queue lengths in RabbitMQ, log important events, and use tools to trace a request as it flows through multiple services. This visibility is not optional; it’s essential for debugging and maintaining performance.
Building systems this way changes how you think about application flow. Your services become independent, reactive pieces. They are easier to scale, update, and reason about. Start with a single event between two services. See how it feels.
Did you find this breakdown helpful? Have you faced challenges with synchronous service calls before? Building this way requires a shift in mindset, but the payoff in system resilience is immense. If this guide clarified the path for you, please share it with a colleague or leave a comment below with your thoughts. Let’s keep the conversation on modern architecture going.
