A loadbalancer is a system that distributes incoming network traffic across multiple servers to ensure no single server get overwhelmed.

So,cool enough this is a bookish answer to the defination of load balancer.

Now let me get to the core of the assignment i got..

You are required to redesign the load balancer logic. The task includes two provided code

components:

1. Code to generate random IP addresses.

2. Code to determine which node is hit.

Cool now what is the actual deal here that as the number of nodes increases the client hitting the server is constantly hitting the wrong node which actualy create a good level of problem.

And this is something we are going to fix in this project or task

This is the fix of the problem at a very beginner level.

So now lets start coding the solution.

So first to do the maths around the ip address we need to find the hashed versions for ip address generated so that when we hit a simulate route we can check which ip is hiiting which

// lets create a hash function to generate a hash value for the incoming ip adresses
function hashIP(ip){
    let hash = 0;
    for(let i = 0; i<ip.length;i++){
        hash = (hash * 31 + ip.charCodeAt(i)) % 1000000007; 
    }
    return hash;
}

hash = (hash * 31 + ip.charCodeAt(i)) % 1000000007;

Reason behind using this formula is it keeps precision keeps the number small and prevent overflow and makes the distribution good.

NOW

The major logic of load balancer.

First we generate the hash value of ip and then find the modulus of that hashed ip with the no of nodes present in our system so that it can allot the unique node for the unique hashed ip which keeps the consistency same for the ip when used again later

const nodes = ["Node-A", "Node-B", "Node-C"];
function identifyNode(ip, selectedNode) {
console.log(`Incoming IP: ${ip} → Routed to: ${selectedNode}`);
}
function LoadBalancer(ip) {
    const hashvalue = hashIP(ip);
    const nodeindex = hashvalue % nodes.length;
    const selectednode = nodes[nodeindex];
    identifyNode(ip, selectednode);
    return selectednode;
}

Used the function identifynode to log the ip and selected node in the terminal

Now this is the major part of the solution now we can make routes over this functions to get the the data in json form when used a cli like postman.

app.post("/route",(req,res)=>{
    const {ip} = req.body;
    if(!ip){
        return res.status(400).json({
            msg:"ip adress is not entered"
        })
    }
    const result = LoadBalancer(ip);
    res.status(200).json({
        msg:"request routed successfully",
        node:result
    })
})

This works when you put a ip in json form in postman and check the route as a real client.

The simulation route when we use generated random ip

app.get("/simulate",(req,res)=>{
    const count = parseInt(req.query.count) || 10; // defaulted to 10 if not provided 
    const results = []// made a in memory database to store the results of the simulation
    for(let i  = 0; i<count; i++){
        const randomip = generateRandomIP();
        const node = LoadBalancer(randomip);
        results.push({
            ip:randomip,
            node:node
        })
    }
    res.status(200).json({
        msg:"simulation completed",
        data:results
    })

})

Ok i agree this can also be done by just writing a basic function which can be..

function simulateTraffic(requestCount = 5) {
for (let i = 0; i < requestCount; i++) {
const ip = generateRandomIP();
LoadBalancer(ip);
}
}
// Run simulation for 10 requests
simulateTraffic(10);

this also works but i preferred writing a route on this.

Hence as you can see the problem is solved.

Now if today i hit my post route with one ip and again i hit it with same ip by twm or any other day it will always hit the same node as usual.

Will bring up the scalable solution also on the load-balancer blog but as of now this is the solution for fix nodes in the system.

Ok so i added bonus endpoint what if my node is down so lets add a healthcheckup endpoint

// helath check for nodes
const nodestatus = {
    "Node-A": true,
    "Node-B": true,
    "Node-C": true
}
function LoadBalancer(ip) {
    const hashvalue = hashIP(ip);
    const nodeindex = hashvalue % nodes.length;
    const selectednode = nodes[nodeindex];
    while(!nodestatus[selectednode]){
        nodeindex = (nodeindex+1)%nodes.length;
        selectednode = nodes[nodeindex];
    }
    identifyNode(ip, selectednode);
    return selectednode;
}

// health check endpoint for nodes
app.post("/health",(req,res)=>{
    const {node,status} = req.body;
    if(!nodestatus.hasOwnProperty(node)){
        return res.status(400).json({
            msg:"invalid node name"
        })
    }
    nodestatus[node]= status;
    res.status(200).json({
        msg:"node status updated successfully",
        node:node,
        status:status
    })
})

Thanks for reading hope you loved it and you coded the same.

Not for production. Not for users. Just to answer one nagging question — what actually happens behind the scenes when two people swipe right at the same time?

Every time I used Tinder, it felt instant.

You swipe right… and somehow the system knows when it’s a match. No delay. No visible complexity. Just a clean “It’s a Match!” moment.

And that curiosity stayed in my head.

Surface-level answers weren’t enough. “They use databases” and “they use APIs” don’t explain anything meaningful. I needed to understand: how does the data flow? Where does it live? How does the system avoid showing you the same profiles twice?

So I built a simplified version myself — not to ship it, but as a proof of work to understand the system at a deep level.

The full source is on GitHub: requiremen/Tinder-backend-core

Here’s how every part of it works.

The Tech Stack

• Node.js — runtime
• Express.js — HTTP server and routing
• MongoDB + Mongoose — database and schemas
• JWT — authentication tokens
• bcrypt — password hashing

Step 1 — Foundation: app.js & Server Setup

Every real system starts somewhere modest. The entry point is src/app.js — it wires together Express, MongoDB, and all route groups:

// src/app.js
const express = require('express');
const mongoose = require('mongoose');
require('dotenv').config();

const authRoutes  = require('./routes/authRoutes');
const userRoutes  = require('./routes/userRoutes');
const swipeRoutes = require('./routes/swipeRoutes');

const app = express();
app.use(express.json());

app.use('/api/auth', authRoutes);
app.use('/', userRoutes);
app.use('/', swipeRoutes);

mongoose.connect(process.env.MONGO_URI)
  .then(() => app.listen(3000, () =>
    console.log('Server running on http://localhost:3000')
  ));

No magic here — just a clean separation of concerns from day one. Each route group lives in its own file. The app file is responsible for nothing except assembly.

Step 2 — Data Models: User, Swipe, Match

The three Mongoose models define the entire shape of the system. Understanding these models is understanding the app.

userModel.js

// src/models/userModel.js
const mongoose = require('mongoose');

const userSchema = new mongoose.Schema({
  name:     { type: String, required: true },
  email:    { type: String, required: true, unique: true },
  password: { type: String, required: true }, // bcrypt hash — never plain text
  age:      { type: Number },
  bio:      { type: String },
}, { timestamps: true });

module.exports = mongoose.model('User', userSchema);

swipeModel.js

// src/models/swipeModel.js
const mongoose = require('mongoose');

const swipeSchema = new mongoose.Schema({
  from:      { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  to:        { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  direction: { type: String, enum: ['like', 'pass'], required: true },
}, { timestamps: true });

module.exports = mongoose.model('Swipe', swipeSchema);

Key insight: A swipe isn’t an animation — it’s just data. Two ObjectIDs and a direction string. That’s the entire abstraction.

matchModel.js

// src/models/matchModel.js
const mongoose = require('mongoose');

const matchSchema = new mongoose.Schema({
  users: [{ type: mongoose.Schema.Types.ObjectId, ref: 'User' }],
}, { timestamps: true });

module.exports = mongoose.model('Match', matchSchema);

The match model is intentionally minimal — just an array of two user IDs. The $all operator later uses this shape to prevent duplicate matches efficiently.

Step 3 — Authentication & JWT Middleware

Before the system can know who liked whom, it needs to know who’s making each request. The auth service handles signup and login, and a middleware guards every protected route.

authService.js

// src/services/authService.js
const bcrypt = require('bcrypt');
const jwt    = require('jsonwebtoken');
const User   = require('../models/userModel');

const signup = async ({ name, email, password }) => {
  const hashed = await bcrypt.hash(password, 10);
  const user   = await User.create({ name, email, password: hashed });
  return user;
};

const login = async ({ email, password }) => {
  const user  = await User.findOne({ email });
  if (!user)  throw new Error('User not found');

  const valid = await bcrypt.compare(password, user.password);
  if (!valid) throw new Error('Invalid credentials');

  const token = jwt.sign(
    { userId: user._id },
    process.env.JWT_SECRET,
    { expiresIn: '7d' }
  );
  return { token, user };
};

module.exports = { signup, login };

Important: Passwords are never stored in plain text. bcrypt.hash() with a salt round of 10 ensures that even if your database leaks, user passwords remain unreadable.

authMiddleware.js

// src/middleware/authMiddleware.js
const jwt  = require('jsonwebtoken');
const User = require('../models/userModel');

const protect = async (req, res, next) => {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer '))
    return res.status(401).json({ error: 'No token provided' });

  const token = authHeader.split(' ')[1];
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = await User.findById(decoded.userId).select('-password');
    next();
  } catch {
    res.status(401).json({ error: 'Invalid or expired token' });
  }
};

module.exports = { protect };

The middleware attaches the full user object (minus the password) to req.user. Every downstream controller can then access the logged-in user without an extra database call.

Step 4 — The Swipe System

The swipe service is the heart of user interaction. It handles three things: preventing self-swipes, preventing duplicate swipes, and storing the result.

swipeService.js

// src/services/swipeService.js
const Swipe = require('../models/swipeModel');
const Match = require('../models/matchModel');

const handleSwipe = async (fromId, toId, direction) => {
  // Guard: can't swipe on yourself
  if (fromId.toString() === toId.toString())
    throw new Error('Cannot swipe on yourself');

  // Guard: already swiped this person
  const existing = await Swipe.findOne({ from: fromId, to: toId });
  if (existing) throw new Error('Already swiped on this user');

  // Store the swipe
  await Swipe.create({ from: fromId, to: toId, direction });

  // Only check for a match on 'like'
  if (direction === 'like') {
    const reverseSwipe = await Swipe.findOne({
      from: toId,
      to:   fromId,
      direction: 'like',
    });

    if (reverseSwipe) {
      // Prevent duplicate match documents using $all
      const matchExists = await Match.findOne({
        users: { $all: [fromId, toId] }
      });

      if (!matchExists) {
        await Match.create({ users: [fromId, toId] });
        return { match: true, message: "It's a match! 💘" };
      }
    }
  }

  return { match: false };
};

module.exports = { handleSwipe };

The $all operator on the match check is the key to deduplication. It finds documents where the users array contains both IDs in any order — so [A, B] and [B, A] are treated as the same match.

Step 5 — Match Logic: The Core Insight

This was the part I was most curious about when I started, and the answer turned out to be a single database lookup.

A match is just:

User A likes User B
AND
User B likes User A

When User A swipes right on User B, the backend immediately asks: “Did B already like A?” If yes — create a match. If no — store A’s swipe and wait.

The match endpoint then fetches all matches for a user, populating both user documents while deliberately stripping passwords:

// src/services/userService.js
const getMatches = async (userId) => {
  const matches = await Match.find({
    users: userId
  }).populate('users', '-password');

  return matches;
};

Calling .populate('users', '-password') replaces ObjectID references with real user objects. The '-password' projection ensures sensitive data never leaves the server.

When I saw that first “It’s a match!” response from my own backend — even just in a terminal window — it genuinely felt exciting. Understanding why it works makes the moment hit differently.

Step 6 — The Discover Feed

The feed needs to feel endless and fresh — but must never surface a profile the current user has already swiped on. Here’s how the feed service builds that filtered list:

// src/services/userService.js
const getFeed = async (userId) => {
  // 1. Find everyone the current user has already swiped
  const mySwipes = await Swipe.find({ from: userId });
  const seenIds  = mySwipes.map(s => s.to);

  // 2. Exclude self + already-seen profiles
  const excludeIds = [...seenIds, userId];

  // 3. Return only unseen users
  const feed = await User.find({
    _id: { $nin: excludeIds }
  }).select('-password').limit(20);

  return feed;
};

The $nin (not in) operator does all the heavy lifting. What remains after filtering is a clean list of profiles the user has never seen — that's the entire illusion of infinite, fresh discovery.

In production systems like Tinder, this query is augmented with geolocation, preference filters, and a ranking model. But the core exclusion logic is exactly this pattern.

Step 7 — Refactoring Into Real Architecture

At this point the system worked — but everything was in a few large files. Refactoring into a layered architecture is where the real engineering lesson happened.

src/
 ├── models/       userModel.js · swipeModel.js · matchModel.js
 ├── controllers/  authController.js · swipeController.js · userController.js
 ├── services/     authService.js · swipeService.js · userService.js
 ├── routes/       authRoutes.js · swipeRoutes.js · userRoutes.js
 ├── middleware/   authMiddleware.js
 └── app.js

Each layer has one job and only calls the layer below it:

• routes/ — defines URL and HTTP method
• controllers/ — handles request/response cycle
• services/ — contains business logic
• models/ — defines data shape
• middleware/ — auth guard

Here’s what that looks like in practice:

// src/routes/swipeRoutes.js
const express  = require('express');
const router   = express.Router();
const { swipe } = require('../controllers/swipeController');
const { protect } = require('../middleware/authMiddleware');

router.post('/swipe', protect, swipe);

module.exports = router;

// src/controllers/swipeController.js
const { handleSwipe } = require('../services/swipeService');

const swipe = async (req, res) => {
  try {
    const { toId, direction } = req.body;
    const result = await handleSwipe(req.user._id, toId, direction);
    res.json(result);
  } catch (err) {
    res.status(400).json({ error: err.message });
  }
};

module.exports = { swipe };

The controller knows nothing about database queries. The service knows nothing about HTTP. This separation means you can swap MongoDB for Postgres, or replace JWT with OAuth, without touching your business logic. That’s the real value of clean architecture — it isn’t just about tidiness, it’s about change tolerance.

Step 8 — The Full System in One View

User logs in
    ↓
Gets JWT token → sent with every request
    ↓
Middleware verifies identity → attaches user to req
    ↓
GET /feed → excludes seen profiles via $nin
    ↓
POST /swipe → stores interaction in DB
    ↓
Check reverse swipe → did they already like me?
    ↓
Mutual like → Match.create({ users: [A, B] }) ❤️
    ↓
GET /matches → populate + return both users

API Endpoints

Method Route Description POST /api/auth/signup Register new user POST /api/auth/login Login, receive JWT GET /me Get own profile PUT /me Update bio, age, etc. POST /swipe Like or pass a user GET /matches All mutual matches GET /feed Unseen users to swipe

All routes except signup and login require Authorization: Bearer <token> in the request header.

What This Project Taught Me

This wasn’t just about cloning an app. It taught me:

Backend is about data relationships, not just APIs. The interesting question is never “how do I write a route” — it’s “how does data connect to itself.”

Simple logic powers complex systems. The match detection is 5 lines. The feed filter is 4 lines. The complexity you feel as a user is mostly UI — the backend logic is remarkably compact.

Database queries are the real brain. $nin and $all aren't just operators. They're the feed and the match system. The query is the feature.

Structure matters as much as functionality. Writing code that works and writing code that scales are two completely different skills. Both take deliberate practice.

Most importantly — I stopped memorizing syntax and started understanding systems. That’s a completely different mode of learning, and a far more durable one.

What’s Next for This Project

• 💬 Real-time chat with Socket.io
• 📍 Location-based matching
• 🎯 Filters for age, gender, and preferences
• 🔔 Push notifications
• 📱 React Native frontend

Check Out the Code

The full source is available on GitHub: 👉 requiremen/Tinder-backend-core

If this helped you understand how backend systems actually work — give it a star. And if you have questions about any part of the implementation, drop them in the comments.

Curiosity built this. Not tutorials. Not copying. Just one question — “how does this actually work?” — followed all the way down to the database query.

console.log("1 script runs")
setTimeout(function(){
    console.log(("2 setTimeout runs,macrotask"))
},0)
Promise.resolve().then(function(){
    console.log("3 promise runs,microtask")
})
console.log("4 script ends")

look at this and think over what the output could be….

1 script runs
4 script ends
3 promise runs,microtask
2 setTimeout runs,macrotask

this is something shows that both of the async task we are performing but the micro-task is running fast and where the core macro-task which is itself a async function is running last.

So basically now let me think over this and show you also lol…

Now what i think the promise.resolve() looks like that it resolves very fast like having a empty function which have a new promise which only returns promise.resolve() lets check with that code as well

console.log("1 script runs")
setTimeout(function(){
    console.log(("2 setTimeout runs"))
},0)

function emptyPromise(){
    return new Promise(function(resolve,reject){
        resolve()
    })
}

Promise.resolve().then(emptyPromise).then(function(){
    console.log("3 promise runs")
})
console.log("4 script ends")

okay now this empty promise function is resolving directly and taking the lowest time as compared to the the timeout task. So yes i might be wrong at this i need review of you guys but lets look forward for some more cool things

Callback hell..

So how does callback hell looks like

// lets have discussing aboout callback hell
setTimeout(function(){
    console.log("hi there")
    setTimeout(function(){
        console.log("welcome to callback hell")
        setTimeout(function(){
            console.log("lets get started")
        },3000)
    },2000)
},1000)

this is how it looks like very clichee way to look at too many timeouts,so this is the reason coders prefer yousing promises to get out of it but hey let me also show you that, for that first lets write out our promisified version of setTimeout()

function settimoutpromise(ms){
    return new Promise(function(resolve,reject){
        if(ms<0){
            reject("invalid time")
        }else{
        setTimeout(resolve,ms)
        }
    })
}

okay so this the promisified version of the settimout using the promise class itself now the lemme show how the call back hell will look in this as well lol..

settimoutpromise(1000).then(function(){
    console.log("hi there")
    settimoutpromise(2000).then(function(){
        console.log("welcome to callback hell")
        settimoutpromise(3000).then(function(){
            console.log("lets get started")
        })
    })

})

lol this seem to look like a promise hell but yes it can be chained in a proper manner lemme show you that now..

settimoutpromise(1000)
.then(function(){
    console.log("hi there")
    return settimoutpromise(2000)      
}).then(function(){
    console.log("welcome to callback hell")
    return settimoutpromise(3000)
}).then(function(){
    console.log("lets get started")
}).catch(function(err){
    console.log(err)
})

now this is how it looks in a chain format

So ultimately promise is better than callback hell its just because it is more readable syntax and easy to digest thats solve.. cool

Ok so promise is an object of an promise class which called to perform various asynchronous task and as of now we have seen timeout read and stuffs but in real life it is all about Database calls and Network calls.

So lets get into the promise now we will get into writing promises

Okay so promise have 3 states

Pending,Fulfilled,Rejected — — -> these are the 3 states of promise

// writing the promisfied version of the fs.readFile function
// writing the promisified version of setTimeout function
// writing the promisified version of fs.writeFile function
// okay first letscatchup with the basic
function readfilepromise(filename,encoding){
    return new Promise();
}
// okay this is an empty promise 
//lets look at how the hell it is called 
const p  = readfilepromise("a.txt","utf-8").then(function(data){
    console.log(data);
    
}).catch(function(err){
    console.log(err);
    
})


// . then method is conatining the callback function which is called when the promise is resolved 
// and the catch method is called when the promise is rejected

look at the comments of the codebase it will get clear with time

const p  = readfilepromise("a.txt","utf-8").then(function(data){
    console.log(data);
    
}).catch(function(err){
    console.log(err);
    
})

for once consider promise function as a black box and marinate the stuff of calling a promise function

Okay so now understand this the promise class wants a function inside it which is its object maybe called new Promise like new Rectangle in the previous blog so its the responsibility of the class to run that function

So lets say that the promise class is written in such way that it requires function as an input

return new Promise(function(){})

got it…

so now a promise is written on the already made asynchronous call back function for here the example is fs.readFile ok so lets write it

function readfilepromise(filename,encoding){
    return new Promise(function(resolve,reject){
        fs.readFile(filename,encoding,function(err,data){
            if(err){
                reject(err);
            }else{
                resolve(data);
            }
        })
    })
}

So here the promisified version of the readfile is made in which the promise is taking a function as argument and then it contains 2 arguments resolve or reject which bascially written to use .then and .catch so that whenever any one of them is call the resolve or the reject argument of the promise class is called which we have given in the arguments of the function inside the new promise(fn).

So now i think you guys can imagine how the promise class may look like

class promise(){
constructor(fn)
}
rsolve()
reject()

all in all it might look like this and hence with clarity we have made a promisified version of readfile.

Okay i got very great insight as well would love to share as well setInterval this thing resolves multiple times and its not the best practise to write a promisified way of setinterval its just only written for a function which only resolves one time max. cool info tho..

Okay so lets put this into testing too will the promise resolve multiple times

let p = new Promise(function(resolve, reject){
    resolve("helllo world");
    resolve("hello world again");
    resolve("hello world again and again");
})
p.then(function(data){
    console.log(data);
})

the output be only hello world which actually proves that it resolves just one time.

thats it for today ……..

Event loop is something is which is constantly looking up at the call stack whether is there any callbacks in the callback queue it will push the first callback from the callback queue into the call stack for execution.

Callback queue — — → contains callback list who are waiting for the execution once the call stack is empty and hence,These tasks are added to the queue by Web APIs after they have completed their operation.

Web APIs are provided by the browser (or the Node.js runtime) and allow you to perform tasks that are outside the scope of the JavaScript language itself, such as making network requests, setting timers, or handling DOM events.

synchronous and asynchronous nature of javascript is the best part of it which makes the thing very easy for building web apps

In a layman terms async nature of javascript can be considered as deligate the task to someone you continuing with other task and conming back to it once the callback is called lol. I really hope you understand this.

classes is the coolest stuff i have seen in javascript it just lets you add functions and properties to any variable you have created according to the class

here we can see that according to the class we implemented the feature into the variable this the magic of classes.

Other than that javascript provides its own class such as the date class

const d = new date() — — → syntax of using classes (this is class provided by javascript itself)

so this class now exposes a bunch of functions with you

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date consider this to know about the functions being exposed by the date class for you

static methods

class rectangle {

constructor(width,height,color){

this.width = width;

this.height = height;

this.color = color;

}

static who(){

return “this is a rectamgle”

}

area(){

return this.width* this.height;

}

}

// static method is somethinng that is called on the class itself not required to called on an a object

let rect1 = new rectangle(10,20,”red”);;

console.log(rect1.who())// this will give an error because who is a static method and we are trying to call it on an object

console.log(rectangle.who())// this will work because we are calling the static method on the class itself

console.log(rect1.area())// this will work because area is not a static method and we are calling it on an object

this is for better under-satanding

Inheritance in js allows you to inherit common properties from all the classes into another parent class which enables the childeren to call out the parent class for it to take the input for example

Now we can define a commom shape class which will be considerd as parent class and then henceforth called out

the syntax for it could be.

The shape class is now the parent class and now we can call color easily in the children class.

Now the given the code here in the ss shows a major problem of hoisting now whats hoisting — → hoisting in javascript is something related to delceleration of a function before calling it assume you are making a call without phone but the function of phone of phone should be defined first to use that phone to make a call, hence over here the shape function should be called first before extending any children class to parent class, ooh cool i have one more example of it it can be having childeren without parents lol. but yeah this is basic hoisting in js.

Now let me start with some difficult bits according to me about the promise class so basically promise is also a class used to perform some async task lets say reading a file setting a timeout….etc

So as of now we know that setTimeout is a async task and it can be called using a callback function this was how the things were being managed back in 2014 but from 2015 some good genius folks wrote the promise class which may have the then() function inside it catch() function inside it and what not.

So now the major bit of writing a promisified version of a readfile

now this looks big but yes this is syntactical sugur. makes easier to understand the code instead of writing basic stuff .then() shows that when ever the task is done pls callback a anaother function .catch() shows if err comes pls call another function and these then and catch is a function installed in the promise class itself

Would love to discuss more on my future vlogs………goodnight everyone.