DEV Community: Mouloud hasrane

How a Simple Screen Share Feature Turned Into a WebRTC Rabbit Hole

Mouloud hasrane — Mon, 13 Jul 2026 12:47:54 +0000

Introduction

I've spent way too much time trying to come up with some generic introduction for this story, but then I realized none of you probably want to read that anyway. So instead, I'll just jump straight into the story—which is why you're here in the first place.

The day I received the requirements

The story begins when I received the requirements for a new feature that allows Teachers to share their presentation to review slides before the Lecture begins, so we would have teachers aids using the web version and seeing a screenshare from the main pc powerpoint, at first I thought maybe we can use HLS or RTMP for this and be okay with the 3 seconds delay that it has, but then I continued reading the ticket, we also needed the user to move to the next and previous slides via the web application, which immediately threw my initial idea out of the window. This is because if the user needs to interact with the application there is no way it will be usable without almost immediate feedback.

Since we needed to show this to the client quickly we had 2 weeks to implement this feature, so before I did anything, I stopped and started drafting a simple design doc, which besides the fancy name was really just a document with my raw notes taken from research and comparisons between different solutions.

After spending some time doing research and looking into different architectures and engineering blogs from companies like Twitch, Slack and Discord, I narrowed the possibilities down to four common architectures used for this type of use case.

Architecture Options

P2P Mesh

This approach revolved around a user establishing WebRTC connections with every other user in the room. Besides being difficult to manage in terms of connections and sessions, it had one fatal flaw: network and CPU overhead.

If we had twenty users in the room, every participant would maintain nineteen separate peer connections while sending nineteen streams, quickly consuming both CPU and bandwidth.

MCU (Multipoint Control Unit)

Going back into server-client architectures, an MCU attempts to centralize media by ingesting streams from producers, multiplexing them together, and then sending the processed result to consumers.

This makes connection management significantly easier since every client only sends and receives a single stream.

The downside is that multiplexing introduces additional latency while also making the server responsible for expensive media processing. Since our entire requirement revolved around low latency, this wasn't the direction we wanted to take.

SFU (Selective Forwarding Unit)

This was the most promising option.

Like an MCU, clients only connect to a central server, but instead of processing the media, the server simply forwards streams from producers to consumers.

That means:

much lower latency,
significantly lower server CPU usage,
far better scalability than a mesh network.

Given our requirements, this immediately became the strongest candidate.

Hybrid (Mesh + SFU)

Another common approach is dynamically switching between Mesh and SFU depending on participant count or network conditions.

In theory this offers the best of both worlds.

In practice, it also means maintaining two completely different implementations.

Given our timeline, this was quickly ruled out.

Custom WebRTC implementation

Another approach worth mentioning is modifying WebRTC itself to fit the use case.

Discord, for example, has invested heavily in custom WebRTC optimizations, but doing something similar requires an entire engineering team working at a much lower level than what was realistic for our project.
While not realistic for most teams , it can be still a fun read discord

The MediaSoup Journey

After sending over the architecture document and discussing the trade-offs, we settled on the SFU approach.

The next question became:

How do we actually build one?

We weren't going to implement an SFU from scratch, so I started looking for existing libraries.

The first thing that caught my attention was MediaSoup.

It was extremely popular, battle-tested, and had a very well-designed architecture, so naturally it became the first solution I experimented with.

The Express wrapper and why

So after reading the docs thoroughly and understanding the all the components well I realized something very important , media soup has some class clients that we need to track their state in memory , and as we all know State is evil, so there was no way I add this to the core api server , so I decided to create a separate express server that will act as a wrapper around media soup and handle all the state management and client connections and sessions , this way we can keep the core api server stateless and also we can easily scale the express server if needed without affecting the core api server , I also made this wrapper open source since I thought it might be useful for other people who want to use mediaSoup
and expirement with it , it is still not a production ready yet! since there are some few stuff missing example of that can be implementing horizonatl scaling (which is not as scary as it sounds when hearing statefull server since mediaSoup already has a mechanism to deal with this in place), all contributions are welcome MediaSoup wrapper

The web proof of concept

it took just few hours to have the media soup up and running , so now I need it to test how everything works together , so I created simple web application that just connects to the api and starts a screenshare session while other clients , watch that screenshare , I tweaked the api a bit , modified ips stuff , but eventually it worked like a charm , better thatn I even Imagined , the delay was very low and the quality was great , I was very happy with the results and I thought that we are good to go and start working on the flutter library and integration with the core api server .

The Flutter library modification journey

Well ..., after the proof of concept was done , I went looking for flutter libraries that can work with media soup , and guess what ? the only libraray I found had the last commits 2 years ago at that time , but I still was optimistic since it is mostly the same protocol and the same architecure , how bad can it be right?, so with my previous experience in flutter I ran the app locally added the libraray , integrated with our server and started testing , and ironicaly media soup V3 decided to change the way that it handles dtls handshakes and session management , you can imagine how that went , but still I said how bad can it be (spoilers alert it was very bad), I spent a week trying to tweak the library, going deeper and deeper into the layer of abstraction and down the rabit hole as well , until I finally gave up and said that this is not the right solution for us , we need to look for other solutions that are more compatible with flutter and have better support for it , so I went back to the drawing board and started looking for other solutions that can fit out solutions .
Also I already wasted 4-5 days trying to do this so for the next parts I had to move quickly

Searching for the correct tool (2 days left)

After spending almost a week trying to make MediaSoup work with Flutter, it became clear that continuing wasn't the right decision.

With only two days left before the demo, I went back to researching alternatives.

After another long night of searching I narrowed the remaining candidates down to three.

Janus

Janus is a very powerfull battle tested sfu that many big companies used including slack when they first launched their calls feature back on 2016 , it has a very good documentation but it also had a lot of features and a lot of integration to setup which made it very hard for use to fully understand the documentation and how to integrate it in only 2 days.

MediaMTX

MediaMtx is a promising famous repo with over 18k stars on github , however internally it is not an sfu per say but a Media server and proxy so it is similar to an MCU rather than an SFU, tho it had a good features I decided to move away from it in the meantime

SRS (Simple Realtime Server)

SRS is a simple and easy to use streaming server that supports variety of protocols which includes (hls, rtmp , webrtc, sfu , mcu ,whip-whep...etc) , And we were already hosting it on our own server for normal hls streaming purposes so we had a lot of experience with it and we knew how to integrate it with our existing infrastructure , it also had a very good documentation and a very active community which made it very easy for us to understand how to use it and how to integrate it with our existing infrastructure .

There was also another solution I never evaluated: LiveKit. Had I looked at it earlier I might have gone with it instead, although given the time constraints I still think familiarity and existing infrastructure would probably have outweighed technical elegance.

What we ended up choosing

At this point you can probably guess what we chose.

We ended up going with SRS for several reasons:

We were already hosting it.
We already knew how to operate it.
Integration with our existing infrastructure was straightforward.
Documentation was excellent.
The community was active.
It fit the timeline better than every other option.

Final Thoughts

If I want the reader to take away just one thing from this story, it's pragmatism.

Most of the time, you won't have the luxury of unlimited time or constraint-free requirements. Engineering isn't always about choosing the technically best solution—it's about choosing the solution that best fits your constraints, your team, and your timeline.

That's exactly what happened here. SRS wasn't necessarily the "best" solution on paper, but it was the one that fit our constraints, integrated well with our existing infrastructure, and allowed us to deliver the feature on time. In the end, that's what mattered.

A deep dive on how backend servers handles HTTP connections

Mouloud hasrane — Tue, 23 Sep 2025 11:27:31 +0000

Introduction

Imagine this scenario: you’ve built a backend application, tested it on your localhost, and the requests are blazing fast with minimal resource usage. But when the server load increases, requests slow down or even start to time out. You’re left scratching your head — is the problem in the backend logic, the programming language, the database queries, the hosting machine, or the reverse proxy?

In this article, we’ll take a deep dive into how backend HTTP requests are executed under the hood. By understanding what your server is actually doing, you’ll be better equipped to identify performance bottlenecks.

How TCP Connections Are Established

We won’t go into too much depth here, just enough lingo to follow the rest of the article. (If you’d like a deep-dive on TCP itself, drop a comment and I’ll write a separate post.)

TCP uses a three-way handshake:

SYN: the client sends a sync request to the server.
SYN/ACK: the server acknowledges and responds with its own sync request.
ACK: the client acknowledges, and both sides are in sync.

At this point, the TCP connection is established.

👉 Why TCP?

Because HTTP/1.1 and HTTP/2 — the most widely used versions — are built on top of TCP. (HTTP/3 uses QUIC, a different protocol, which we won’t cover here.)

The Kernel’s Role

When you send an HTTP request to a server, the Linux kernel manages it using two queues:

1. The SYN Queue

This queue holds half-open connections. After the server replies with SYN/ACK but before the client’s final ACK, the connection sits here.

2. The Accept Queue

Once the handshake is complete, the connection is moved to the accept queue. At this point, the kernel is done — it’s up to the backend application to pick it up using the accept() syscall.

Important detail: if the accept queue is full, new connections will be dropped (or reset). This is controlled by the kernel parameter:

cat /proc/sys/net/core/somaxconn
-> 128

(default is often 128). Increasing this can help servers under heavy load.

Another detail: if the ack from clients takes too long the kernel automatically drops the connections

The Backend Application’s Role

After a connection enters the accept queue, the application must call the accept() syscall to start handling it.

Your application’s concurrency performance depends on how quickly it can:

Accept new connections.
Execute requests without blocking other connections.

How Different Backends Handle Connections

We need to distinguish two phases:

Accepting connections: how the server calls accept().
Executing connections: how the HTTP request itself is processed.

Node.js

Single-threaded for both accepting and executing requests.
Famous for non-blocking I/O. While a request is waiting for an I/O operation (like a DB query), Node.js can accept new connections.

👉 Problem: if a request is CPU-bound (e.g., a huge loop or sync file read), the event loop blocks. Other requests won’t even be logged until the CPU task finishes.

Example:

import express from 'express';
const app = express();
const LIMIT = 1_000_000_000;

function processData() {
  let sum = 0;
  for (let i = 0; i < LIMIT; i++) sum += i;
  return sum;
}

app.get('/blocking', (req, res) => {
  console.log('Blocking request received');
  const result = processData();
  res.send(`Result is ${result}`);
});

app.listen(3000);

Call /blocking twice in quick succession: the second request won’t even log until the first finishes.

Go

Accepts connections on the main thread.
Immediately spawns a goroutine for each request, leaving the main thread free to keep accepting new ones.

From the net/http docs:

Serve accepts incoming connections, creating a new service goroutine for each. The service goroutines read requests and then call the handler to reply.

This model balances simplicity with concurrency.

Python (WSGI servers like Gunicorn/uWSGI)

Concurrency depends on workers (threads or processes).
When a connection is accepted, it’s assigned to a worker.
Multiple workers prevent one slow request from blocking others.
CPU-bound workloads still block individual workers, so scaling often means running multiple processes.

PHP (Apache/Nginx + PHP-FPM)

The web server (Apache or Nginx) handles connection management.
Each request is passed to a PHP worker (via mod_php or PHP-FPM).
Requests run in isolated processes, so one request won’t block another — but each worker is heavier than a lightweight goroutine or async event loop.

Others (quick mentions)

Java (Servlets, Tomcat, Netty): thread-per-request (Tomcat) or event-driven (Netty).
Rust (Tokio, Actix): async event loops, similar to Node.js but highly optimized.

Useful Commands

Play around with these to observe queues and connections:

cat /proc/sys/net/ipv4/tcp_max_syn_backlog   # max SYN queue length
cat /proc/sys/net/core/somaxconn             # max accept queue length
ss -tln                                      # show sockets + queue info
netstat -anp                                 # legacy alternative

For load testing:

ab -n 1000 -c 100 http://localhost:3000/
wrk -t12 -c400 -d30s http://localhost:3000/

Conclusion

By now, you should have a clearer picture of what happens when a client connects to your backend:

The kernel manages the handshake and queues.
The backend application must efficiently accept() and execute connections.
Different runtimes handle this differently: event loops, goroutines, workers, or processes.

Key takeaway: performance issues often aren’t just about your code or your database queries — they can stem from queue limits, blocking workloads, or how your runtime handles concurrency.

In part two, we’ll look at how the kernel manages sending responses using the send/receive queues (sendq and recvq).

WebSocket Authentication in NestJS: Handling JWT and Guards

Mouloud hasrane — Sat, 09 Aug 2025 12:16:19 +0000

When working with WebSockets in NestJS using gateways, developers quickly encounter a fundamental challenge: traditional authentication guards don't work seamlessly with JWT tokens, especially short-lived ones. Unlike HTTP requests where each call can be independently authenticated, WebSocket connections are persistent, creating unique authentication requirements.

The Core Problem

NestJS guards are designed for request-response cycles, but WebSockets maintain long-lived connections. If you're using short-lived JWT tokens and attempt to verify authentication on each message, the token will eventually expire mid-connection, breaking the user experience. This leaves developers with a few viable approaches.
Guards Are more Usefull in Ws context With AuthZ (Authorization) like RBAC (message spececif)

Authentication Strategies

Session-Based Authentication

The most straightforward approach is using session-based authentication, where guards can function normally since sessions persist across the connection lifecycle. However, this approach may not suit all architectural requirements, particularly in stateless or distributed systems.

Long-Lived Token Method

One workaround is generating a long-lived token specifically for WebSocket connections during the initial handshake. This token gets attached to the client and acknowledged, allowing the connection to remain authenticated for its entire duration. While effective, this approach requires careful token management and potential security considerations around longer token lifespans.

Normal access tokens - refresh Tokens

This method is basically trying to recreate the flow of normal http access -refresh tokens jwt authentication , but Emitting a refresh token event to the server on Unauthorized Ws Exception and then waiting for an ack from the server with the new access and refresh tokens , this can work sure ! , but it can also cause problems at scale (parsing the jwt on each websocket message, connections management ...etc) , and requires more client side configuration.

Handshake-Only Verification

The most common approach is to verify authentication only during the WebSocket handshake. Once the connection is established and authenticated, subsequent messages are trusted. This balances security with practicality, though it requires careful connection management.

The Gateway Architecture Challenge

Here's where NestJS WebSocket implementation presents an interesting architectural challenge. When you have multiple gateways operating on the same namespace, any connection initialization logic defined in one gateway applies to all gateways in that namespace (this is not anywhere on the docs this was found with trial and error), and we are going to use that to in our favor to create a centralized Auth logic handler for our gatewatys

The Gateway Extension Pattern

The solution lies in creating a structured hierarchy of gateway classes that properly separate connection management from business logic.

Step 1: Create a Base WebSocket Manager

First, create a base gateway class (commonly named WSManager or WebSocketManager) that handles all connection-related logic:


export class WSManager implements OnGatewayInit, OnGatewayConnection {
//Use Property based injection on the parent class to avoid passing them on the sub-classes constructor
//class ref is the key of the provider change this if you have custom provider defenition 
@Inject(AuthenticationService)
private readonly  authService:AuthenticationService
  constructor()
  handleConnection(client: Socket, ...args: any[]) {
    // Handle authentication logic here
    // Verify JWT on handshake
    const token=client.handshake.authentication.token
    const user=this.authService.validateToken(token)
    if(!user){
          client.disconnect(true)

}
    // Set up client metadata
    client.user=user
  }

  afterInit(server: Server) {
    // Server initialization logic
  }
}

ps:you can add the @webSocketGateway() decorator to this class if you have the default namespace and you don't want to extend this on the gateways related to it

Step 2: Extend for Specific Functionality

For each specific WebSocket feature (notifications, chat, real-time updates, etc.), create dedicated gateways that extend the base manager:
so what will happen here is the notification Gateway will extend the WsManger implementation of the handleConnection from the WsManager

@WebSocketGateway({ namespace: '/notifications' })
export class NotificationGateway extends WSManager {
constructor(){
super()
}

  @SubscribeMessage('subscribe-to-notifications')
  handleNotificationSubscription(client: Socket, data: any) {
    // Notification-specific logic
    // Connection is already authenticated via parent class
  }
}

Important Note

If you have a custom logic of the after Init other than Authentication Something like RBAC or Rooms joining logic , you can implement the OnGatewayConnection on the intended NameSpace while keeping the same logic as before by Calling

super.handleConnection()

@WebSocketGateway({ namespace: '/chat' })
export class NotificationGateway extends WSManager {
constructor(private readonly chatService:ChatService){
//Important here to call super for dependency injection to work
super()
}
 handleConnection(client: any, ...args: any[]) {
    super.handleConnection(client, ...args);
    //Available now since it was set on the base Class
    const user=client.user
    const canConnect=this.chatService.canConnect(user)
    if (!canConnect){
    //Custom Exception
      throw New ConnectionException('Cannot connect to the chat service')
    }
    const room=extractRoomfromHandShake(client.handshake)
    client.join(room)
  }

  @SubscribeMessage('sendMessage')
  handleSendMessage(client: Socket, data: any) {

    // Connection is already authenticated via parent class and the user in the correct room(s)
  }
}

Conclusion

The gateway extension pattern solves the fundamental challenge of WebSocket authentication in NestJS by separating connection management from business logic. This approach provides:

Centralized Authentication: All connection security logic in one reusable class
Clean Architecture: Business logic gateways focus on their specific domain
Maintainability: Changes to authentication flow only require updates in one location
Scalability: Easy to add new WebSocket features without duplicating authentication code

While NestJS WebSocket authentication presents unique challenges compared to traditional REST endpoints, understanding the connection lifecycle and leveraging proper inheritance patterns creates a robust, maintainable solution that scales with your application's needs.
Remember to always validate your authentication approach based on your specific security requirements and consider implementing additional measures like rate limiting and connection monitoring for production environments.

Mastering Microservices with NestJS: A Practical Guide to Scalable Architectures

Mouloud hasrane — Thu, 20 Feb 2025 00:35:12 +0000

Ever wondered how tech giants like Netflix, Uber, and Amazon handle millions of requests without breaking a sweat? The secret lies in microservices architecture—a game-changing approach that makes applications more scalable, resilient, and easier to maintain.

In this guide, we'll demystify microservices, explore their benefits, and walk through a hands-on implementation using NestJS and RabbitMQ. Ready to level up your backend skills? Let’s dive in! 🚀

📌 Why NestJS?

One of the standout features of NestJS is its native support for microservices architecture. When using microservices in NestJS, you can still leverage decorators, guards, pipes, interceptors, and other features found in a traditional monolithic NestJS app.

Before we jump into the code, let’s break down what microservices are and why they are so powerful.

🏗️ What Are Microservices?

In a typical monolithic architecture, a single server handles all requests, processes the logic, and returns a response.

In contrast, a microservices architecture breaks down an application into multiple independent services, each handling a specific piece of logic.

Instead of one big server doing everything, we have multiple smaller services (often called microservices) working together.

🛠️ Why Microservices?

✅ Separation of Concerns & Decoupling:

Each microservice is responsible for a specific aspect of the application, making it easier to scale and debug.

✅ Fault Tolerance:

If one service goes down, only that part of the app is affected, not the entire system.

✅ Scalability & Performance:

Since services are independent, they can be scaled individually based on demand.

Now after that, you might Ask : Now, you might ask: how do these services communicate with each other?

Ande we need to introduce the concept of a transport layer, you can imagine it for now as the route or the bridge that links all of the services together it sends data across multiple services :fmo us transport layers are :

TCP
RMQ
BullMq
Grpc and a lot more.

What is cool about nests that is allows you to use your preferred transport layer from the multiple ones it offers and you can easily change it in the configuration without changing the code later (say you are using Tcp and after a while, you wanted to switch over to a message queue like RMQ you just have to change it in the configuration of the module without changing anything in the code)

Before we jump into coding (I know it took too long but this is not your average code tutorial blog we need to understand what exactly each piece of code does when we write it) we need to discuss one last thing that is the types of microservices, in this context ,we are focusing on types regarding how are req-res are handled and we will focus on 2 types:

Request-response (Message pattern):

Here we send a message( which is just a piece of data) over to the right service over a transport layer, and then wait for it to return a response to use

Event-based

Here we are also sending a message or in this case, it is called an event but we don't actually expect or wait for a response instead side effects are just happening in the appropriate service(s) In most cases events are unidirectional meaning that the data only goes in one way

now that we have a basic understanding of what micro services architecture is all about let's dive into how to implement it using nestJs

Example of A micro Services System

here is what a micro Services system look like

NestJs Implementation:

We will try to build a simple e-commerce example to showcase microServices in nests

First we Create a normal nests application this application is often called the producer because unlike other nodes it is an HTTP app that is responsible for getting the requests and sending them to the appropriate service
then we need to install the microServices module

$ npm i --save @nestjs/microservices

3 . Install the transport layer here I'm using Rabbit mq feel free to use anyone you like (check the documentation for supported Transport layers)

$ npm i --save amqplib amqp-connection-manager

We define a simple dto for validation

  import { IsEmail, IsNumber, IsString } from 'class-validator';

export class orderDto {
  @IsString()
  product: string;
  @IsEmail()
  email: string;
  @IsNumber()
  quantity: number;
}

Then we register our services inside the app Module or the feature module if you want better separation, using the microservices module that we just downloaded here we will only use the payment and orders service

 import { OrdersController } from './orders.controller';
import { ClientsModule, Transport } from '@nestjs/microservices';

 @Module({
  imports: [
    ClientsModule.register([
      {
        name: 'ORDER_SERVICE',
        transport: Transport.RMQ,
        options: {
          URLs: ['amqp://localhost:5672'],
          queue: 'order_queue',
          queueOptions: {
            durable: true, // Make the queue persistent
          },
          // Specify an exchange
        },
      },
    ]),
  ClientsModule.register([
      {
        name: 'PAYMENT_SERVICE',
        transport: Transport.RMQ,
        options: {
          URLs: ['amqp://localhost:5672'],
          queue: 'payment_queue',
          queueOptions: {
            durable: true, // Make the queue persistent
          },
          // Specify an exchange
        },
      },
    ]),

  ],
  controllers: [OrdersController],
  providers: [OrdersService],
})
export class OrdersModule {}

Here I'm using RabbitMq which is a powerful message queue
a message queue: is a transport layer that uses the FIFO Data structure and holds the messages in a queue until the first message gets processed by the consumer (service), what is cool about it is that if the consumer is down it will wait until it is up again (unlike tcp for example which if the service is down the message will just be lost)

Here is a simple controller that handles 2 requests

/* eslint-disable prettier/prettier */
import { Body, Controller, Post } from '@nestjs/common';
import { OrdersService } from './orders.service';
import { orderDto } from './orderDto';

@Controller('orders')
export class OrdersController {
  constructor(private read-only ordersService: OrdersService) {
  }
  @Post()
  OrderAdded(@Body() order:orderDto){
     return this.ordersService.handleOrder(order);
  }
  @Post('/pay')
  payOrder(@Body() order:orderDto){
    return this.ordersService.handle payment(order);
  }
}

And this is the service

import { Inject, Injectable } from '@nestjs/common';
import { orderDto } from './orderDto';
import { ClientProxy } from '@nestjs/microservices';

@Injectable()
export class OrdersService {
   constructor(@Inject("ORDER_SERVICE") private RSERVICE:ClientProxy,@Inject('PAYMENT_SERVICE') private PAYMENTQueue:ClientProxy  ){}
  handleOrder(order :orderDto){
   this.RSERVICE.emit('ORDER_PLACED',order);
    return {message:"ORDER ADDED!"}
  }
   handle payment(order: orderDto) {
    this.PAYMENTQueue.emit('PAYMENT',order);
    return {
      message: 'PAYMENT DONE!',
    }
  }
}

Here is where the magic happens first we Inject services registered earlier in the module and then we emitting events the first String in the emit method is the event pattern which is how the service now what logic to execute and the second param is the payload which is the actual data that the service needs to work with.
here we are using .emit because we are using event-based architecture
if you want to use a message you just use .send instead

And then we need to create another nest application which is the service itself here is how to define the main of the app

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

async function bootstrap() {
  const app = await NestFactory.createMicroservice(AppModule, {
    transport: Transport.RMQ,
    options: {
      URLs: ['amqp://localhost:5672'],
      queue: 'order_queue',
      queueOptions: {
        durable: true,
      },
    },
  });
  await app.listen();
}
bootstrap();

what changes that we create a microService instead of a nest application and then we define the appropriate transport layer that this service uses to communicate with the producer
and here is to define the controller to handle upcoming events

 import { Controller } from '@nestjs/common';
import { OrdersService } from './orders.service';
import { Ctx, EventPattern, Payload, RmqContext } from '@nestjs/microservices';
import { OrderDto } from './orderDto';

@Controller('orders')
export class OrdersController {
  constructor(private readonly ordersService: OrdersService) {}
  @EventPattern('ORDER_PLACED')
  handleOrders(@Payload() order: OrderDto, @Ctx() context: RmqContext) {
    return this.ordersService.handleOrder(order);
  }
}

note that the Event Pattern is the same one we sent Earlier
here we get Acces to the payload that we send and the Excution context which contains some metadata that are out of the scope of this article
what cool now is that we can register another Service inside this service and send events to it as well like we're doing here in the service

import { Inject, Injectable } from '@nestjs/common';
import { ClientProxy } from '@nestjs/microservices';
import { OrderDto } from './orderDto';

@Injectable()
export class OrdersService {
  constructor(
    @Inject('PAYMENT_SERVICE') private readonly paymentClient: ClientProxy,
  ) {}
  handleOrder(order: OrderDto) {
    console.log('PROCESSING ORDER', order);
    console.log('SENDING ORDER TO PAYMENT SERVICE');
    this.paymentClient.emit('PAYMENT', order);
  }
}

and Payment Client is another service built just like this one

In this article, we explored how to build a microservices architecture using NestJS and RabbitMQ. We discussed the benefits of microservices, such as scalability, fault tolerance, and separation of concerns, and demonstrated how NestJS simplifies inter-service communication.

By leveraging RabbitMQ as a message broker, we ensured reliable, asynchronous communication between services, making our system more resilient and efficient. The flexibility of NestJS also allows us to switch transport layers easily, giving us the freedom to adapt to different use cases.

As you continue building microservices, consider factors like service discovery, monitoring, and security to enhance your system further. Experiment with different transport layers, and explore tools like Kubernetes for orchestration. Microservices can be complex, but with the right tools and architecture, they can unlock powerful scalability and maintainability for your applications. 🚀

Understanding Replication and Sharding in System Design

Mouloud hasrane — Wed, 29 Jan 2025 00:11:59 +0000

When discussing system design, terms like sharding, partitioning, replication, and master-slave relationships frequently come up. If these concepts seem confusing, don't worry! This article will clarify the differences between replication and sharding to help you build a solid foundation in distributed database systems.
ps: images are from building data intensive systems book be sure to check it out

Replication

Replication involves creating multiple instances of a database that contain the same data as the main instance. This allows requests to be distributed among replicas, improving system performance and availability. But how do we decide which requests go to which instance? Replication can be categorized into different types, but in practice, two are most commonly used:

1. Master-Slave Replication (Leader-Follower Replication)

In this model, a leader (master) database handles both read and write operations, while followers (slaves) handle only read operations. Any write operation made to the leader is replicated to the followers, either synchronously or asynchronously (we’ll discuss these approaches in detail in a future article).

Why is this useful?

Most systems are read-heavy rather than write-heavy, meaning they perform far more read operations than writes. By distributing read queries to multiple followers, we can significantly reduce the load on the leader instance, improving performance and scalability.

2. Master-Master Replication (Leader-Leader Replication)

Now, imagine our system has grown to the point where we need multiple data centers worldwide to minimize latency. If we rely on leader-follower replication, choosing a single leader across all data centers would lead to slow write operations for users far from that leader.

With leader-leader replication, each data center has its own leader. When a write operation is performed at one leader, it is propagated to all other leaders, which then replicate it to their followers, in other words each leader acts as a follower to the leader that just got the write operations and then as a leader to send the new data to his followers
Challenges:

While this approach improves performance and fault tolerance, it introduces challenges such as write conflicts, where two leaders handle conflicting writes at the same time. Handling such conflicts requires careful resolution strategies, such as conflict-free replicated data types (CRDTs) or last-write-wins (LWW) mechanisms.

Sharding

Unlike replication, which creates copies of the same database, sharding (also called partitioning) splits the database into smaller subsets, called shards, each containing a portion of the data. This allows for better scalability by distributing requests across multiple shards.
How do we determine which shard a request should go to?

Two common techniques for sharding are:

1. Key Range Sharding

In this approach, data is divided into shards based on a predefined range of values. Think of it like an encyclopedia where different volumes contain different alphabetic sections of words.

Example: User IDs from 1–1000 go to Shard A, 1001–2000 go to Shard B, and so on.

Advantage: Simple to implement.

Disadvantage: Can lead to hot spots—if a specific range receives more requests than others, that shard will become overloaded.

2. Hash-Based Sharding

Here, a hash function is applied to a data attribute (e.g., User ID) to determine which shard should store the data. A well-designed hash function distributes data evenly across shards.

say for example If hash(UserID) % 3 == 0, the request is sent to Shard A; if hash(UserID) % 3 == 1, it goes to Shard B, and so on.

Advantage: Ensures even distribution and prevents hot spots.

Disadvantage: Can make it difficult to perform range queries, as data is spread across multiple shards unpredictably.

Rebalancing Shards

As data grows and system demands change, sharded databases must be rebalanced to maintain efficiency. This involves redistributing data and queries among nodes while minimizing disruptions. Rebalancing is crucial to:

Prevent overload on specific shards.

Maintain system availability for read/write operations.

Minimize data movement to reduce network and disk I/O overhead.

We will discuss different rebalancing strategies and common pitfalls in a future article.

why bother using any of those techniques :

as the system scales up or single instance database will not be able to handle all of the request efficiently, which will cause reduce the response time , that will affect the user experience which in of itself will affect our sales and user count, you may think no problem let's just get a stronger pc that can handle those request , but as we keep scaling up the hardware will be costly and hard to find (you'll reach a point when you have the most powerful disk out there to run you db on ),for that reason we use this strategies to keep or response time and overall experience smooth no matter how much our app scales.
Final Thoughts

Now that you have a fundamental understanding of replication and sharding, you can explore their trade-offs and edge cases in greater detail. Each technique has its own benefits and challenges, and the best approach depends on your system’s requirements.

Stay tuned for more in-depth articles on advanced replication strategies, handling conflicts in distributed databases, and optimizing sharding techniques!

Happy learning! 🚀