DEV Community: Mouloud hasrane

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! 🚀