DEV Community: Roshan singh

# 🚀 Idempotency Keys in Payment APIs: Preventing Duplicate Transactions Explained

Roshan singh — Thu, 23 Jul 2026 11:56:23 +0000

Have you ever wondered:

"Why don't payment apps charge me twice if I accidentally click the Pay button multiple times?"

"What happens if my internet disconnects while making a payment?"

The answer is Idempotency.

If you're learning backend development, this is one of those concepts every backend engineer should understand.

Let's learn it from scratch.

🤔 The Problem

Imagine you're buying a laptop online.

You click the Pay button.

Client
   |
   |------ Pay ₹50,000 ------>
   |
Server

The server starts processing your payment.

But suddenly...

Your internet becomes slow.
The server successfully processes the payment.
The response never reaches your phone.

Now your app thinks:

"Maybe the payment failed."

So it retries automatically.

Client

Pay ₹50,000
------------>

(No response)

Retry
------------>

Retry Again
------------>

Now the server receives three identical requests.

❌ Without Idempotency

The backend processes every request independently.

Request 1
Charge ₹50,000 ✅

Request 2
Charge ₹50,000 ✅

Request 3
Charge ₹50,000 ✅

Result:

Customer Paid ₹150,000 ❌

Even though the customer clicked only once.

This is one of the biggest problems backend systems need to solve.

Why Do Duplicate Requests Happen?

Duplicate requests happen all the time.

User double-clicks the button.
Internet connection becomes slow.
Mobile network reconnects.
Browser refreshes.
HTTP client automatically retries.
Load balancer retries.

Your backend must handle these situations safely.

✅ The Solution: Idempotency

Idempotency simply means:

Sending the same request multiple times should have the same effect as sending it once.

The backend should process the request only once.

Every duplicate request should simply return the previous response.

How Does It Work?

Every request carries a unique value called an Idempotency Key.

Example:

POST /payments

Idempotency-Key: abc123

Think of it as a unique tracking number for a request.

First Request

The frontend sends:

POST /payments

Idempotency-Key: abc123

Backend receives it.

It asks:

Have I seen "abc123" before?

Database:

No

Since it's a new request, the backend:

Charges the customer
Creates the order
Stores the key
Stores the response

Database:

Key        Response
-----------------------------
abc123     Payment Successful

Finally it returns:

{
    "status": "success",
    "orderId": 101
}

Retry Happens

Because of a network timeout, the client retries.

It sends the same key.

POST /payments

Idempotency-Key: abc123

Backend checks again.

Have I seen abc123?

Database:

YES ✅

Instead of charging again...

The backend simply returns the stored response.

{
    "status": "success",
    "orderId": 101
}

No duplicate payment.

No duplicate order.

No duplicate database entries.

Visual Flow

                First Request

Client
   |
   | Pay ₹1000
   | Key = abc123
   |
   v

Server

Have I seen abc123?

        |
      No |
        |

Process Payment

Save

abc123 -> Payment Success

Return Response

----------------------------------------

              Retry

Client
   |
   | Pay ₹1000
   | Key = abc123
   |
   v

Server

Have I seen abc123?

        |
      Yes
        |

Return Stored Response

(No Payment Again)

Who Generates the Idempotency Key?

Usually, the frontend (React, Angular, iOS, Android, etc.) generates it.

Example:

const key = crypto.randomUUID();

This key is attached to the request.

⚠️ A Common Beginner Mistake

Many people think:

"If the request fails, I'll generate another key."

That's wrong.

Suppose the first request uses:

abc123

The retry uses:

xyz999

The backend sees two completely different keys.

abc123 ❌

xyz999 ❌

It thinks:

"These are two different payment requests."

So it charges twice.

Idempotency completely fails.

✅ The Correct Way

Generate the key once.

Reuse it for every retry.

const key = crypto.randomUUID();

try {

    await sendPayment(key);

} catch {

    // Retry with SAME key

    await sendPayment(key);

}

Notice something?

const key = crypto.randomUUID();

is executed only once.

Frontend Example

async function pay() {

    // Generate only ONCE

    const key = crypto.randomUUID();

    try {

        await sendPayment(key);

    } catch {

        console.log("Retrying...");

        // Retry using SAME key

        await sendPayment(key);

    }

}

async function sendPayment(key) {

    return fetch("/api/payment", {

        method: "POST",

        headers: {

            "Content-Type": "application/json",

            "Idempotency-Key": key

        },

        body: JSON.stringify({

            amount: 1000

        })

    });

}

Backend Pseudo Code

@app.post("/payment")

def payment(request):

    key = request.headers["Idempotency-Key"]

    # Have we already processed this request?

    if database.contains(key):

        return database.get_response(key)

    # First time seeing this request

    payment = charge_customer()

    database.save(
        key=key,
        response=payment
    )

    return payment

That's the entire idea behind idempotency.

Where Is the Key Stored?

Usually in a database.

Example:

+----------------------------------------+
| Idempotency Table                      |
+----------------------------------------+

Key           Response

------------------------------------------

abc123        Order #101

xyz456        Order #102

mno888        Payment Failed

------------------------------------------

Many production systems use Redis because it's much faster than querying a database.

Which HTTP Methods Need Idempotency?

GET

GET /users/1

Already idempotent.

Calling it 100 times doesn't change anything.

PUT

PUT /users/1

Updating the same resource multiple times results in the same final state.

Already idempotent.

DELETE

DELETE /users/1

Deleting an already deleted resource still leaves the system in the same state.

Also idempotent.

POST

POST /payments

POST usually creates a new resource.

Calling it multiple times creates multiple records.

That's why POST endpoints commonly use Idempotency Keys.

Where Is Idempotency Used?

Almost every payment platform.

Stripe
Razorpay
PayPal
PhonePe
Google Pay
Amazon Pay

It's also widely used in:

Order Creation
Flight Booking
Hotel Booking
Wallet Recharge
Subscription Creation
Invoice Generation

Basically...

Anywhere duplicate processing would cause serious problems.

Real-Life Analogy

Imagine you're ordering pizza.

You call the restaurant.

"One Large Pizza."

The phone disconnects.

You don't know whether they heard you.

You call again.

Without idempotency:

Pizza
Pizza
Pizza

Three pizzas arrive.

With idempotency:

The restaurant checks your order number.

"We've already received Order #123."

No new pizza is prepared.

Key Takeaways

✅ One business operation = One Idempotency Key

✅ Every retry uses the same key

✅ The backend stores the key after processing

✅ Duplicate requests return the previous response

✅ No duplicate payments

✅ No duplicate orders

Final Thoughts

Idempotency is one of those backend concepts users never notice—but they benefit from it every day.

The next time your payment succeeds after a network timeout, or you don't get charged twice after accidentally clicking Pay multiple times, you'll know there's an idempotency mechanism working behind the scenes.

Good backend systems aren't just about making things work.

They're about making sure they can't accidentally work twice. 🚀

## JavaScript Async vs Python AsyncIO — The Simplest Explanation for JavaScript Developers

Roshan singh — Tue, 21 Jul 2026 12:28:09 +0000

If you're coming from JavaScript, Python's asyncio can feel confusing.

I had the same question:

"Why do I need asyncio? JavaScript never makes me import anything."

After understanding both, I realized the concepts are almost the same.

The biggest difference is who provides the event loop.

JavaScript

In JavaScript, the runtime (Browser or Node.js) already provides an event loop.

When you write:

async function getUsers() {
    console.log("Before");

    const response = await fetch("https://jsonplaceholder.typicode.com/users");

    console.log("After");
}

getUsers();

What happens?

Before

(fetch request sent)

JavaScript Event Loop

↓

Runs other work while waiting

↓

API responds

↓

After

You never think about the event loop because it already exists.

The Browser (or Node.js) manages everything for you.

Python

Now let's write the same thing in Python.

import asyncio
import httpx

async def get_users():
    print("Before")

    response = await httpx.AsyncClient().get(
        "https://jsonplaceholder.typicode.com/users"
    )

    print("After")

asyncio.run(get_users())

This looks very similar.

The difference is:

Instead of the Browser/Node.js providing the event loop automatically,

Python uses asyncio.

async function
        ↓
await
        ↓
asyncio Event Loop
        ↓
Network request
        ↓
Resume coroutine

The Biggest Difference

This is the one thing every JavaScript developer should remember.

JavaScript

Calling an async function starts it immediately.

async function hello() {
    console.log("Hello");
}

hello();

Output:

Hello

Python

Calling an async function does NOT execute it.

async def hello():
    print("Hello")

hello()

Output:

Nothing

RuntimeWarning:
coroutine 'hello' was never awaited

Why?

Because Python only creates a coroutine object.

To execute it, you need:

asyncio.run(hello())

await hello()

asyncio.create_task(hello())

await Works Almost the Same

JavaScript

async function signup() {

    console.log("Start");

    await fetch("/users");

    console.log("Done");
}

Python

async def signup():

    print("Start")

    await httpx.AsyncClient().get("/users")

    print("Done")

In both languages:

The current function pauses.
The event loop continues doing other work.
When the API responds, execution resumes.

So if you already understand JavaScript's await, you already understand most of Python's await.

What Does asyncio.create_task() Mean?

Suppose sending an email takes 5 seconds.

You don't want your user to wait.

JavaScript

async function signup() {

    await saveUser();

    sendEmail(); // Don't await

    return "User Created";
}

The email starts in the background while the response is returned immediately.

Python

async def signup():

    await save_user()

    asyncio.create_task(send_email())

    return "User Created"

Exactly the same idea.

The difference is that Python explicitly asks the event loop to schedule the coroutine.

When Should You Use await?

If the next line depends on the result, use await.

user = await save_user()

Examples:

Database queries
API calls
Reading files asynchronously
Cache lookups

When Should You Use create_task()?

Use it only for background work.

Examples:

Send email
Push notification
Analytics event
Logging
Cleanup jobs

asyncio.create_task(send_email())

Don't wait for it.

Continue immediately.

Don't Use Async for Everything

This is another common mistake.

Normal calculations don't need async.

def add(a, b):
    return a + b

result = add(5, 10)

No await.

No asyncio.

No event loop.

Async is mainly useful for I/O-bound operations, such as:

HTTP requests
Database queries
File I/O
Redis
WebSockets

JavaScript vs Python Cheat Sheet

JavaScript	Python
`async function`	`async def`
`await fetch()`	`await httpx.get()`
Browser/Node.js Event Loop	`asyncio` Event Loop
`setTimeout()`	`asyncio.sleep()`
Promise	Coroutine
`sendEmail()` (don't await)	`asyncio.create_task(send_email())`

Mental Model

If you're coming from JavaScript, remember this sentence:

JavaScript has a built-in event loop managed by the Browser or Node.js. Python exposes its event loop through the asyncio library.

Everything else—async, await, pausing while waiting for I/O, and resuming execution—works very similarly.

Once I stopped thinking of asyncio as "something new" and instead saw it as Python's version of the JavaScript event loop, the whole concept became much easier to understand.

# The Journey of a Request: How NGINX Routes Traffic Between Docker Containers in a Modern Web Application

Roshan singh — Wed, 15 Jul 2026 04:35:50 +0000

The Journey of a Request: From Browser to Database and Back

Have you ever wondered what actually happens after you type a website URL into your browser?

Let's follow the complete journey of a request in a typical production web application.

Our Production Architecture

Imagine we have four Docker containers running on the same server.

                           Docker Network
┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│                    ┌──────────────────┐                             │
│                    │      NGINX       │                             │
│                    │   (Port 80/443)  │                             │
│                    └────────┬─────────┘                             │
│                             │                                       │
│              ┌──────────────┴──────────────┐                        │
│              │                             │                        │
│              ▼                             ▼                        │
│      ┌───────────────┐             ┌───────────────┐                │
│      │   Frontend    │             │    Backend    │                │
│      │    :3000      │             │     :5000     │                │
│      └───────────────┘             └───────┬───────┘                │
│                                            │                        │
│                                            ▼                        │
│                                   ┌────────────────┐                │
│                                   │   PostgreSQL   │                │
│                                   │     :5432      │                │
│                                   └────────────────┘                │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

                    ▲
                    │
            Internet (Browser)

Only NGINX is exposed to the internet.

The Frontend, Backend, and PostgreSQL containers communicate over Docker's internal network. Users can never access these containers directly.

A minimal NGINX reverse proxy configuration looks like this:

server {
    listen 80;
    server_name myapp.com;

    # Website requests
    location / {
        proxy_pass http://frontend:3000;
    }

    # API requests
    location /api/ {
        proxy_pass http://backend:5000;
    }
}

This configuration tells NGINX:

Requests to / should go to the Frontend container.
Requests beginning with /api should go to the Backend container.

This makes NGINX the single entry point for every incoming request.

Now let's follow an actual request from start to finish.

Step 1: The User Opens the Website

The user enters:

https://myapp.com

The browser doesn't immediately know where this website is hosted.

It first asks the DNS (Domain Name System):

"What's the IP address for myapp.com?"

DNS responds with the server's public IP address.

User
   │
   ▼
Browser
   │
DNS Lookup
   │
Returns Server IP

Now the browser knows exactly where to send the request.

Step 2: The Browser Sends the First Request

The browser sends its first HTTP request:

GET /

This request reaches the server.

Since only NGINX is exposed to the internet, it receives every incoming request first.

Browser
    │
GET /
    │
NGINX

Think of NGINX as the receptionist of a company.

Every visitor first speaks to the receptionist before being directed to the correct department.

Step 3: NGINX Routes the Request to the Frontend

NGINX examines the request.

Since the request is for /, it forwards it to the frontend application (for example, React, Angular, Vue, or Next.js).

Browser
     │
NGINX
     │
Frontend Application

The frontend returns:

HTML
CSS
JavaScript
Images
Fonts

NGINX sends these files back to the browser.

Step 4: The Browser Builds the User Interface

The browser downloads all the assets.

It parses the HTML, loads the CSS, executes the JavaScript, and finally renders the application on the screen.

At this point, the user can interact with the application.

Step 5: The User Clicks a Button

Suppose the user clicks Login.

Or opens the Users page.

Or clicks View Profile.

The frontend now needs data from the backend.

Instead of contacting the backend directly, it makes an API request like:

POST /api/login

GET /api/users

Notice something important.

The browser sends the request to the same domain:

https://myapp.com/api/users

It does not know anything about internal services such as:

backend:5000

Those names exist only inside Docker's private network.

Step 6: NGINX Routes the API Request

The API request once again reaches NGINX.

Browser
     │
GET /api/users
     │
NGINX

NGINX recognizes that the request begins with /api.

Instead of sending it to the frontend, it forwards it internally to the backend application (for example, Express, NestJS, Spring Boot, Django, ASP.NET Core).

Browser
      │
NGINX
      │
Backend Application

The browser never communicates directly with the backend.

Step 7: The Backend Processes the Request

Inside the backend, the request flows through different layers.

Request
   │
Controller / Route Handler
   │
Service Layer
   │
Repository / ORM

Each layer has its own responsibility.

Controller / Route Handler receives the HTTP request.
Service Layer contains the business logic.
Repository / ORM communicates with the database.

This separation of concerns makes applications easier to maintain, test, and scale.

Step 8: The ORM Talks to the Database

Instead of writing raw SQL everywhere, most modern applications use an ORM (such as Prisma, Hibernate, Sequelize, SQLAlchemy, or Entity Framework).

The ORM converts application code into SQL queries.

Application Code
       │
       ▼
ORM
       │
       ▼
SQL Query
       │
       ▼
Database

The database executes the SQL query and returns the requested data.

Step 9: The Response Begins Its Journey Back

The database sends the result back to the ORM.

The ORM returns it to the Service.

The Service returns it to the Controller.

The Controller creates the HTTP response.

Database
      │
ORM
      │
Service
      │
Controller

The backend has now finished processing the request.

Step 10: NGINX Sends the Response Back

The backend sends its response back to NGINX.

NGINX forwards it to the browser.

Backend
     │
NGINX
     │
Browser

The browser receives the JSON response.

The frontend updates the UI automatically, and the user sees the latest data.

Complete Journey

User
 │
 ▼
Browser
 │
 ▼
DNS Lookup
 │
 ▼
Server IP Address
 │
 ▼
NGINX (Reverse Proxy)
 │
 ├────────────────────────► Frontend Application
 │                               │
 │◄────── HTML / CSS / JS ───────┘
 │
 ▼
Browser Renders UI
 │
 ▼
User Clicks Button
 │
 ▼
GET /api/... or POST /api/...
 │
 ▼
NGINX
 │
 ▼
Backend Application
 │
 ▼
Controller / Route Handler
 │
 ▼
Service Layer
 │
 ▼
Repository / ORM
 │
 ▼
Database
 │
 ▲
ORM
 │
 ▲
Service
 │
 ▲
Controller
 │
 ▲
NGINX
 │
 ▲
Browser
 │
 ▲
Frontend Updates UI

Final Takeaways

DNS only tells the browser where the server is located.
NGINX is the single public entry point for every request.
NGINX decides whether a request should go to the Frontend or the Backend.
The browser never communicates directly with backend services or the database.
Backend services communicate with the database over Docker's private network.
The response follows the exact same path back to the browser.

Once you understand this request journey, modern production architectures become much easier to reason about. Whether you're using React, Angular, Vue, Express, Spring Boot, Django, or any other framework, the overall request lifecycle remains fundamentally the same.

What is API Versioning?

Roshan singh — Thu, 02 Jul 2026 10:52:34 +0000

🚀 What is API Versioning? (Beginner Friendly)

If you're learning backend development, you've probably seen APIs like these:

GET /api/v1/users
GET /api/v2/users

The first question most beginners ask is:

Why do we need v1, v2, or v3? Why not just update the existing API?

Let's understand it with a simple example.

📖 What is API Versioning?

API Versioning is a way to make changes to an API without breaking applications that are already using it.

Instead of changing the existing API, developers create a new version.

🧑‍💻 Example

Suppose you have an API like this.

Version 1

Request

GET /api/v1/user

Response

{
  "name": "Roshan",
  "age": 22
}

Everything works perfectly.

🤔 A Few Months Later...

Your company decides that age should no longer be public.

Your first thought might be:

Why not just remove age from Version 1?

Because thousands of applications might already be using this API.

For example, an old mobile app expects this response:

{
  "name": "Roshan",
  "age": 22
}

If you suddenly change the API to this:

{
  "name": "Roshan"
}

the old app may stop working because it was expecting the age field.

✅ The Solution: Create a New Version

Instead of modifying v1, create v2.

Version 2

Request

GET /api/v2/user

Response

{
  "name": "Roshan"
}

Now both versions exist.

/api/v1/user  → Returns name + age
/api/v2/user  → Returns only name

This means:

✅ Old applications continue using v1
✅ New applications use v2
✅ Nothing breaks

❓But Won't Old Users Keep Using v1 Forever?

No.

Here's what usually happens.

Step 1

The old version of your app calls:

GET /api/v1/user

Step 2

You release a new version of your app.

Inside the new app, you change the API call to:

GET /api/v2/user

Step 3

Users update the app from the Play Store or App Store.

After updating, the app automatically starts using v2.

Users don't need to change anything manually.

👴 What About Users Who Never Update?

For some time, they continue using v1.

That's why companies keep older API versions running.

A typical lifecycle looks like this:

Release v1
      │
      ▼
Users start using it
      │
      ▼
Release v2
      │
      ▼
New app uses v2
      │
      ▼
Most users update
      │
      ▼
Announce v1 is deprecated
      │
      ▼
Remove v1

Keeping an old version for some time before removing it is called API Deprecation.

🎯 Why is API Versioning Important?

Prevents existing applications from breaking.
Allows developers to improve the API safely.
Gives users time to update their applications.
Makes it easier to add new features in the future.

📝 Final Thoughts

Think of API versions like software versions.

v1 → Old version
v2 → Improved version
v3 → Latest version

Older applications continue using the version they were built for, while newer applications use the latest version.

That's why you'll often see APIs like:

GET /api/v1/users
GET /api/v2/users
GET /api/v3/users

API Versioning allows your API to evolve without breaking existing applications.

# Webhook vs Polling — Understanding with Real Examples

Roshan singh — Mon, 29 Jun 2026 04:26:27 +0000

When I first started learning backend development, I kept hearing two terms everywhere:

Polling
Webhooks

At first they sounded complicated, but the core idea is simple.

Both are ways for one system to get updates from another system.

The difference is who starts the communication.

What is Polling?

Polling means your application repeatedly asks another server for updates.

Something like:

“Any new updates?”
“Any updates now?”
“What about now?”

Example:

setInterval(() => {
  fetch("/api/status");
}, 5000);

Here, the client checks every 5 seconds.

Real-life Example of Polling

Think about checking your job application status on a company portal.

You log in and see:

Status: Under Review

After 3 days, you refresh the page.

Your browser sends another API request asking:

Has my application status changed?

That refresh is basically manual polling.

Why Polling Can Be Inefficient

Polling is easy to implement, but there’s a problem.

What if nothing changes for hours?

Your application still keeps sending requests.

That means:

Extra server load
Unnecessary network calls
Wasted resources

Imagine 50,000 users checking every few seconds.

That becomes expensive.

What is a Webhook?

Webhook solves this problem.

Instead of repeatedly asking for updates, you provide your server URL to another service.

When something happens, that service sends data automatically.

In simple words:

Don’t ask me repeatedly — I’ll notify you when something changes.

Real-life Example of Webhook

Payment systems are the best example.

Suppose a customer pays using Stripe or Razorpay.

Without webhooks, your backend keeps asking:

Payment successful?

With webhooks, the payment provider instantly sends a request to your server.

Example payload:

{
  "event": "payment.success",
  "orderId": 101
}

Your backend can then:

Mark order as paid
Generate invoice
Send confirmation email

All automatically.

Polling vs Webhook

Feature	Polling	Webhook
Communication	Client asks repeatedly	Server pushes updates
Speed	Delayed	Near real-time
Requests	More	Less
Scalability	Lower	Better

Simple Analogy

Imagine ordering food.

Polling

You call the restaurant every 5 minutes:

“Is my food ready?”

Webhook

Restaurant calls you when food is ready.

That’s the difference.

Final Thoughts

Use Polling when:

Data changes slowly
Simplicity matters
Real-time updates are not required

Use Webhooks when:

Events happen unpredictably
Instant updates matter
Scalability is important

Polling is pull-based communication.

Webhooks are push-based communication.

backend #webdev #systemdesign #javascript #nodejs

LLD Design Process (From Requirements to Code)

Roshan singh — Fri, 19 Jun 2026 04:51:06 +0000

LLD Design Process (From Requirements to Code)

Step 1: Understand Requirements

Before creating any class, understand what the system should do.

Ask:

What features are required?
What operations are supported?
What are the future extensions?

Example: Document Editor

Requirements:

Add Text
Add Image
Add New Line
Add Tab Space
Render Document
Save Document

Never jump directly to classes.

First understand the problem.

Step 2: Extract Nouns → Classes

Nouns in requirements often become classes.

Example

Requirements:

Add Text
Add Image
Save Document

Nouns:

Document
Text
Image
Storage
Editor

Possible classes:

Document
TextElement
ImageElement
Storage
DocumentEditor

Another Example (Parking Lot)

Requirements:

Park Vehicle
Generate Ticket
Multiple Floors

Nouns:

ParkingLot
Floor
Slot
Vehicle
Ticket

These become candidate classes.

Step 3: Find IS-A Relationships → Inheritance

Ask:

"Can I say child IS-A parent?"

Example

TextElement IS-A DocumentElement
ImageElement IS-A DocumentElement
NewLineElement IS-A DocumentElement
TabSpaceElement IS-A DocumentElement

Therefore:

                DocumentElement
                        ▲
                        |
       ----------------------------------
       |         |          |           |
 TextElement ImageElement NewLineElement TabSpaceElement

Code

class DocumentElement {
public:
    virtual string render() = 0;
};

class TextElement : public DocumentElement {};
class ImageElement : public DocumentElement {};

Rule

Use inheritance only when:

Child IS-A Parent

Examples:

Car IS-A Vehicle
Dog IS-A Animal
CreditCardPayment IS-A Payment

Step 4: Find HAS-A Relationships → Composition/Aggregation

Ask:

"What objects are contained inside another object?"

Example

A document contains elements.

vector<DocumentElement*> documentElements;

Meaning:

Document HAS-A collection of DocumentElements

UML:

Document 1 -------- * DocumentElement

Another Example

Parking Lot:

ParkingLot HAS-A Floors
Floor HAS-A Slots

Rule

Use composition/aggregation when:

Parent HAS-A Child

Examples:

Car HAS-A Engine
Document HAS-A Elements
ParkingLot HAS-A Floors

Step 5: Identify Actions → Methods

Ask:

"What actions can objects perform?"

Example

Document Editor:

Add Text
Add Image
Render
Save

Methods:

addText()
addImage()
render()
save()

Parking Lot

Actions:

parkVehicle()
unparkVehicle()
generateTicket()

Methods:

parkVehicle()
unparkVehicle()

Rule

Verbs become methods.

Nouns → Classes
Verbs → Methods

Step 6: Find Variations → Interfaces / Abstract Classes

Ask:

"What can change in the future?"

Example

Saving document:

File
Database
Cloud

These are different implementations.

Create abstraction:

             Persistence
                   ▲
                   |
         --------------------
         |                  |
   FileStorage        DBStorage

Code:

class Persistence {
public:
    virtual void save(string data) = 0;
};

Why?

Tomorrow we can add:

class CloudStorage : public Persistence {};

without changing existing code.

Rule

When multiple implementations exist:

Create Interface / Abstract Class

Examples:

Payment
 ├─ UPI
 ├─ Card
 └─ Cash

Storage
 ├─ File
 ├─ DB
 └─ Cloud

Step 7: Draw UML

After identifying:

Classes
Methods
Inheritance
Composition

Draw UML.

Example

Document
    |
    | contains
    v
DocumentElement
      ▲
      |
-----------------------
|         |           |
Text    Image     NewLine

Persistence
      ▲
      |
---------------
|             |
FileStorage DBStorage

Step 8: Write Code

Convert UML to code.

Abstract Class

class DocumentElement {
public:
    virtual string render() = 0;
};

Child Classes

class TextElement : public DocumentElement {};
class ImageElement : public DocumentElement {};

Composition

class Document {
private:
    vector<DocumentElement*> elements;
};

Dependency Injection

class DocumentEditor {
private:
    Persistence* storage;
};

Interview Thinking Framework

Whenever interviewer gives a problem:

Requirements
      ↓
Nouns
      ↓
Classes
      ↓
IS-A
      ↓
Inheritance
      ↓
HAS-A
      ↓
Composition
      ↓
Verbs
      ↓
Methods
      ↓
Variations
      ↓
Interfaces
      ↓
UML
      ↓
Code

Quick Cheat Sheet

Noun → Class

Vehicle
Ticket
Document
User
Payment

Verb → Method

park()
save()
render()
pay()
login()

IS-A → Inheritance

Car IS-A Vehicle
ImageElement IS-A DocumentElement

HAS-A → Composition

Car HAS-A Engine
Document HAS-A Elements

Future Variations → Interface

Payment
Storage
Notification
Logger

Final Flow:

Requirements
   ↓
Classes
   ↓
Inheritance
   ↓
Composition
   ↓
Methods
   ↓
Interfaces
   ↓
UML
   ↓
Code

# 🚀 Important React Interview Questions Every Developer Must Know

Roshan singh — Fri, 08 May 2026 06:28:56 +0000

If you're preparing for:

React interviews
frontend roles
full stack interviews

these are the most important React concepts you should know.

This guide covers:

core React fundamentals
hooks
rendering
state management
optimization concepts

in a beginner-friendly way.

✅ 1. What is Virtual DOM?

The Virtual DOM is a lightweight JavaScript copy of the real DOM.

Instead of directly updating the browser DOM:

React creates a new Virtual DOM
compares it with the old one
updates only changed parts in the real DOM

This process is called:

⚡ Reconciliation / Diffing

✅ Why is Virtual DOM Fast?

Because:

comparing JavaScript objects is fast
real DOM operations are expensive

React minimizes direct DOM manipulation.

✅ 2. What is useState?

useState is a React Hook used for managing component state.

```jsx id="jlwmn"
const [count, setCount] = useState(0);




* `count` → current state
* `setCount` → updates state

When state changes:

# React re-renders the component

---

# ✅ 3. What is useEffect?

`useEffect` handles:

* API calls
* timers
* subscriptions
* event listeners
* side effects



```jsx id="jlwmm"
useEffect(() => {
  fetchData();
}, []);

✅ Important Point

useEffect runs:

AFTER component render

✅ Dependency Array

Dependency	Behavior
No array	Runs every render
`[]`	Runs once
`[count]`	Runs when count changes

✅ 4. Props vs State

Props	State
Passed from parent	Managed inside component
Read-only	Mutable
Used for communication	Used for dynamic data

✅ 5. What is Redux Toolkit?

Redux Toolkit is used for:

Global State Management

It helps avoid:

prop drilling
deeply nested state passing

✅ Main Concepts

Store
Slice
Reducer
Dispatch

✅ 6. What is RTK Query?

RTK Query simplifies API integration in Redux Toolkit.

It automatically handles:

caching
loading state
errors
refetching

```jsx id="jlwml"
const { data } = useGetUsersQuery();




---

# ✅ 7. Component Lifecycle

React components have 3 lifecycle phases:

1. Mounting
2. Updating
3. Unmounting

Handled using `useEffect`.

---

## ✅ Mount Example



```jsx id="jlwmk"
useEffect(() => {}, []);

✅ Cleanup Example

```jsx id="jlwmj"
useEffect(() => {
return () => {
console.log("cleanup");
};
}, []);




---

# ✅ 8. Controlled vs Uncontrolled Components

---

## ✅ Controlled Component

React controls input state.



```jsx id="jlwmi"
<input value={name} onChange={handleChange} />

✅ Uncontrolled Component

DOM controls input using refs.

```jsx id="jlwmh"




---

# ✅ 9. What is useRef?

`useRef` stores mutable values without causing re-renders.

Commonly used for:

* DOM access
* focusing inputs
* timers
* previous values



```jsx id="jlwmg"
const inputRef = useRef();

✅ 10. API Integration in React

Usually done using:

fetch
axios

Inside useEffect.

```jsx id="jlwmf"
useEffect(() => {
axios.get("/api/users");
}, []);




---

# ✅ fetch vs axios

| fetch               | axios                  |
| ------------------- | ---------------------- |
| Built into browser  | External library       |
| Manual JSON parsing | Automatic JSON parsing |
| More boilerplate    | Cleaner syntax         |

---

# ✅ 11. What is Lifting State Up?

Lifting state up means:

# Moving shared state to the nearest common parent component.

Used when sibling components need same data.

---

# ✅ Example



```jsx id="jlwme"
<ChildA count={count} />
<ChildB setCount={setCount} />

✅ 12. What is Context API?

Context API helps avoid:

Prop Drilling

It allows components to access shared data directly.

✅ Example

```jsx id="jlwmd"
const user = useContext(UserContext);




---

# ✅ 13. What is React.memo?

`React.memo` prevents unnecessary component re-renders.

It uses:

# Shallow Prop Comparison



```jsx id="jlwmc"
export default React.memo(Child);

✅ 14. What is useMemo?

useMemo memoizes expensive calculations or values.

```jsx id="jlwmb"
const value = useMemo(() => calculate(), [dep]);




Recalculates only when dependencies change.

---

# ✅ 15. What is useCallback?

`useCallback` memoizes function references.



```jsx id="jlwma"
const handleClick = useCallback(() => {}, []);

Helps prevent unnecessary child re-renders.

🔥 Most Important React Optimization Concept

React.memo alone is often NOT enough.

Because:

functions
arrays
objects

create new references every render.

So:

useCallback preserves function reference
useMemo preserves value reference

This helps:

✅ React.memo work effectively

📊 Difference Between React.memo, useMemo, useCallback

Feature	React.memo	useMemo	useCallback
Used For	Component	Value	Function
Prevents	Re-render	Recalculation	Function recreation

🎯 Final Interview Tips

For React interviews:

focus on concepts
understand rendering
know how hooks work internally
explain WHY optimizations are needed

Most interviewers care more about:

understanding

than memorizing syntax.

🏁 Final Thoughts

React becomes much easier once you understand:

rendering
component lifecycle
state management
memoization
re-renders

Master these concepts properly and you’ll already know most of the important React interview topics.

React.memo vs useMemo vs useCallback — Complete Guide

Roshan singh — Fri, 08 May 2026 06:25:26 +0000

If you're learning React, you've probably heard these terms everywhere:

React.memo
useMemo
useCallback

At first, they look confusing.

But all three solve one major problem:

⚡ Unnecessary Re-renders & Performance Issues

This guide explains:

what each one does
why they exist
how they are connected
when to use them
interview explanations

🤔 Why Do These Exist?

In React, components re-render very frequently.

A component re-renders when:

state changes
props change
parent component re-renders

Most of the time this is fine.

But in large applications:

expensive calculations
recreated functions
unnecessary child renders

can slow down the application.

That’s why React provides:

React.memo
useMemo
useCallback

for optimization.

🧠 First Understand One Important Thing

In React:

function App() {
  console.log("Rendered");

  return <h1>Hello</h1>;
}

Whenever React re-renders:

the ENTIRE component function runs again
variables get recreated
functions get recreated

This is the root reason why memoization exists.

1️⃣ React.memo

✅ What is React.memo?

React.memo prevents unnecessary component re-renders.

❌ Problem Without React.memo

function Child() {
  console.log("Child rendered");

  return <h1>Child Component</h1>;
}

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      <Child />
    </>
  );
}

🔍 What Happens Here?

When button is clicked:

Parent re-renders
Child ALSO re-renders

Even though:

Child props didn't change
Child state didn't change

❌ This is an unnecessary re-render.

✅ Solution Using React.memo

const Child = React.memo(() => {
  console.log("Child rendered");

  return <h1>Child Component</h1>;
});

Now React remembers the previous render.

If props are unchanged:

✅ Child render is skipped

⚙️ How React.memo Works Internally

React performs:

👉 Shallow Comparison

It compares:

old props
new props

If props are same:
✅ React skips rendering.

📌 Important Point

React.memo works best with:

strings
numbers
booleans

But NOT always with:

functions
arrays
objects

Because they create new references every render.

That’s where useCallback and useMemo help.

2️⃣ useCallback

✅ What is useCallback?

useCallback memoizes functions.

It prevents function recreation on every render.

❌ Problem Without useCallback

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    console.log("Clicked");
  };

  return <Child onClick={handleClick} />;
}

Looks normal, right?

But here's the hidden issue:

🚨 A NEW function gets created on every render

🤯 Why?

Because in JavaScript:

const a = () => {};
const b = () => {};

console.log(a === b);

Output:

false

Because:

both functions have different memory references

🚨 Why This Causes Re-renders

Suppose Child uses:

const Child = React.memo(({ onClick }) => {
  console.log("Child rendered");

  return <button onClick={onClick}>Click</button>;
});

Even with React.memo,
Child STILL re-renders because:

oldFunction !== newFunction

React thinks:

❌ Prop changed

✅ Solution Using useCallback

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

Now React stores:

✅ SAME function reference

between renders.

So:

Child gets same prop
React.memo works properly
unnecessary render avoided

🧠 Behind The Scenes

❌ Without useCallback

Render 1 → new function
Render 2 → new function
Render 3 → new function

✅ With useCallback

Render 1 → create function
Render 2 → reuse same function
Render 3 → reuse same function

3️⃣ useMemo

✅ What is useMemo?

useMemo memoizes values or expensive calculations.

❌ Problem Without useMemo

const filteredUsers = users.filter(user => user.active);

This runs:

🚨 On EVERY render

Even when unrelated state changes.

🤯 Example

Suppose:

theme changes
modal opens
input typing happens

Still:

users.filter()

runs again.

For large data:
❌ performance issue.

✅ Solution Using useMemo

const filteredUsers = useMemo(() => {
  return users.filter(user => user.active);
}, [users]);

Now calculation runs ONLY when:

users

changes.

⚙️ How useMemo Works Internally

React stores:

previous dependencies
previous calculated value

If dependencies don't change:

✅ Cached value is returned

No recalculation happens.

🔥 MOST IMPORTANT — How All Three Are Connected

This is where most beginners get confused.

❌ React.memo Alone Is NOT Enough

Suppose:

<Child
  onClick={handleClick}
  data={filteredUsers}
/>

Even with React.memo,
Child may STILL re-render because:

handleClick creates new function
filteredUsers creates new array/object

React sees:

oldProp !== newProp

because references changed.

✅ That’s Why We Need:

👉 useCallback

to preserve function reference

AND

👉 useMemo

to preserve value/object/array reference

So that:

✅ React.memo can ACTUALLY skip rendering

🧩 Simple Mental Model

✅ React.memo

“Skip component render if props are same.”

✅ useCallback

“Keep same function reference.”

✅ useMemo

“Keep same calculated value/reference.”

📊 Final Difference Between All Three

Feature	React.memo	useMemo	useCallback
Used For	Component	Value	Function
Prevents	Re-render	Recalculation	Function recreation
Returns	Memoized component	Memoized value	Memoized function
Common Use	Child optimization	Expensive calculations	Stable callbacks

🚫 When NOT To Use Them

Do NOT overuse memoization.

These hooks also have overhead.

Use them only when:

unnecessary renders are causing issues
calculations are expensive
components are large/heavy

🎯 Interview Summary

✅ React.memo

Prevents unnecessary component re-renders using shallow prop comparison.

✅ useMemo

Memoizes calculated values and recalculates only when dependencies change.

✅ useCallback

Memoizes function references to prevent unnecessary function recreation and child re-renders.

🏁 Final Thoughts

Most developers memorize:

syntax
definitions

But the REAL understanding is:

React.memo depends on stable references.
useMemo and useCallback help maintain those stable references.

Once this connection clicks, React rendering behavior becomes much easier to understand.

Scaling Redis in Distributed Systems: From Local Cache Problems to Redis Cluster

Roshan singh — Wed, 06 May 2026 12:04:05 +0000

**When building scalable backend systems, one common question arises:

“If we scale our application using multiple instances, how should caching work?”

This becomes especially important when using Redis in distributed architectures.

Let’s understand the problem step by step and then move toward advanced scaling concepts like sharding and replication.**

🚨 The Problem with Local Redis per Instance

Suppose we scale our backend application:

Load Balancer
     ↓
 ┌───────────┐
 │ Instance1 │
 └───────────┘
       │
   Local Redis 1

 ┌───────────┐
 │ Instance2 │
 └───────────┘
       │
   Local Redis 2

At first glance, this looks fine.

But here’s the issue.

Imagine:

User data gets updated through Instance 2
Local Redis 2 gets updated
Local Redis 1 still contains old cached data

Now:

Requests routed to Instance 1 return stale data
Requests routed to Instance 2 return fresh data

This creates:

Cache inconsistency
Synchronization complexity
Stale reads

❌ Why Syncing Local Redis is Difficult

To keep multiple local Redis caches synchronized, we need:

Pub/Sub systems
Event broadcasting
Cache invalidation messaging
Distributed coordination

This becomes very complex at scale.

That’s why production systems usually avoid separate Redis instances per application server.

✅ The Correct Approach: Centralized Redis

Instead of separate caches, all backend instances use a shared Redis layer.

                        ┌─────────────────┐
Client → Load Balancer  → App Instances
                        └─────────────────┘
                              ↓
                     Shared Redis Cluster
                              ↓
                         PostgreSQL

Now:

All instances read/write from the same Redis
Any update becomes immediately visible everywhere
No synchronization problem

Example:

await db.updateUser(id, data);
await redis.del(`user:${id}`);

Once the cache is invalidated:

Any instance fetching the data gets the latest value

This architecture is simple, scalable, and production-friendly.

🤔 But What Happens When Redis Itself Needs Scaling?

A single Redis server has limitations:

Limited memory
Limited CPU
Single point of failure

For very large systems, we need:

Horizontal scaling
Fault tolerance
High availability

This is where Redis Cluster comes in.

🔥 Redis Cluster

A Redis Cluster distributes data across multiple Redis nodes.

It uses two important concepts:

Sharding
Replication

1️⃣ Sharding — Scaling Redis Horizontally

What is Sharding?

Sharding means:

Splitting data across multiple Redis nodes.

Instead of storing all data in one Redis server:

Redis Node 1
→ All users
→ All movies
→ All bookings

Redis distributes keys across multiple nodes.

Example:

user:101    → Node 1
movie:201   → Node 2
booking:301 → Node 3

Important:
Redis does NOT shard by entity type.

It shards based on:

Hash calculation of keys

Internally:

HASH(key) % 16384 = slot

Each node owns a range of hash slots.

Example:

Node 1 → Slots 0–5000
Node 2 → Slots 5001–10000
Node 3 → Slots 10001–16383

✅ Why Sharding is Important

Sharding helps with:

Memory scaling
Traffic distribution
Better performance
Horizontal scalability

Without sharding:

One Redis server becomes overloaded

2️⃣ Replication — High Availability & Failover

What is Replication?

Replication means:

Creating copies of Redis data on replica nodes.

Example:

Master 1 → Replica 1
Master 2 → Replica 2
Master 3 → Replica 3

If:

Master 2 crashes

Redis automatically promotes:

Replica 2 → New Master

This process is called:

Automatic failover

✅ Why Replication is Needed

Sharding distributes data,
but it does NOT protect against node failure.

Without replication:

If a node crashes,
Data on that shard becomes unavailable

Replication provides:

High availability
Fault tolerance
Backup copies
Reduced downtime

⚔️ Sharding vs Replication

Feature	Sharding	Replication
Purpose	Scalability	High Availability
Data	Split	Copied
Increases Memory Capacity	✅ Yes	❌ No
Handles Node Failure	❌ No	✅ Yes
Improves Performance	✅ Yes	Partial

🏗️ Final Production Architecture

Production systems usually combine both:

                Redis Cluster

Master 1 → Replica 1
Master 2 → Replica 2
Master 3 → Replica 3

Here:

Masters handle sharded data
Replicas provide failover protection

🎯 Final Thoughts

When scaling distributed systems:

Avoid local Redis per instance
Use centralized Redis
Scale Redis using sharding
Ensure reliability using replication

This architecture helps achieve:

Low latency
High scalability
High availability
Fault tolerance

Which is exactly what modern distributed systems require.

# How to Build a Complete CI/CD Pipeline with GitHub Actions and Docker Hub

Roshan singh — Wed, 25 Mar 2026 07:16:44 +0000

## Introduction

In this tutorial, I'll show you how to set up a complete CI/CD pipeline that automatically builds Docker images, pushes them to Docker Hub, and deploys your application to a production server - all triggered by a simple git push!

## What You'll Learn

Setting up GitHub Actions for automated builds
Building and pushing Docker images to Docker Hub
Deploying containerized applications to a remote server
Version tagging with Git commit SHAs
Zero-downtime deployments with Docker Compose

## Prerequisites

Before we start, make sure you have:

A GitHub repository with your application code
A Docker Hub account
A remote server (VPS/Cloud VM) with Docker and Docker Compose installed
SSH access to your server
Basic understanding of Docker and Docker Compose

## Architecture Overview

Our CI/CD pipeline consists of two main jobs:

Build & Push: Build Docker images and push them to Docker Hub
Deploy: Pull the new images on the server and restart containers

Git Push → GitHub Actions → Build Images → Docker Hub → Deploy to Server → Live!

## Step 1: Project Structure

Here's what your project structure should look like:

your-project/
├── .github/
│   └── workflows/
│       └── deploy.yml          # CI/CD workflow
├── backend/
│   ├── Dockerfile              # Backend Docker image
│   └── ... (your backend code)
├── frontend/
│   ├── Dockerfile              # Frontend Docker image
│   └── ... (your frontend code)
├── docker-compose.prod.yml     # Production deployment config
└── nginx.conf                  # Nginx configuration

## Step 2: Create Dockerfiles

### Backend Dockerfile Example

# backend/Dockerfile
FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

EXPOSE 5000

CMD ["node", "server.js"]

*### Frontend Dockerfile Example
*

# frontend/Dockerfile
FROM node:18-alpine as build

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

yaml

## Step 3: Create Docker Compose Production File

# docker-compose.prod.yml
version: '3.8'

services:
  backend:
    image: yourdockerhub/crm-backend:${CRM_BACKEND_TAG:-latest}
    container_name: crm-backend
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=${DATABASE_URL}
    ports:
      - "5000:5000"
    networks:
      - app-network

  frontend:
    image: yourdockerhub/crm-frontend:${CRM_FRONTEND_TAG:-latest}
    container_name: crm-frontend
    restart: unless-stopped
    ports:
      - "3000:80"
    depends_on:
      - backend
    networks:
      - app-network

  nginx:
    image: nginx:alpine
    container_name: nginx-proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - frontend
      - backend
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

## Step 4: Create GitHub Actions Workflow

Create .github/workflows/deploy.yml:

name: Build and Deploy to Production

on:
  push:
    branches: [main]

jobs:
  build-and-push:
    name: Build and push Docker images
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Generate image tags
        id: tag
        run: |
          echo "full=${GITHUB_SHA}" >> "$GITHUB_OUTPUT"
          echo "short=${GITHUB_SHA:0:7}" >> "$GITHUB_OUTPUT"

      - name: Build and push backend image
        uses: docker/build-push-action@v5
        with:
          context: ./backend
          file: ./backend/Dockerfile
          push: true
          tags: |
            yourdockerhub/crm-backend:latest
            yourdockerhub/crm-backend:${{ steps.tag.outputs.full }}
            yourdockerhub/crm-backend:${{ steps.tag.outputs.short }}

      - name: Build and push frontend image
        uses: docker/build-push-action@v5
        with:
          context: ./frontend
          file: ./frontend/Dockerfile
          push: true
          tags: |
            yourdockerhub/crm-frontend:latest
            yourdockerhub/crm-frontend:${{ steps.tag.outputs.full }}
            yourdockerhub/crm-frontend:${{ steps.tag.outputs.short }}

  deploy:
    name: Deploy to production server
    runs-on: ubuntu-latest
    needs: build-and-push

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Copy configuration files to server
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_KEY }}
          source: "docker-compose.prod.yml,nginx.conf"
          target: "~/crm-app"

      - name: Deploy application
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd ~/crm-app
            TAG="${{ github.sha }}"

            # Clean up old images
            sudo docker image prune -a -f

            # Pull new images
            sudo docker compose -f docker-compose.prod.yml pull backend frontend

            # Recreate containers with new images
            sudo CRM_BACKEND_TAG="$TAG" CRM_FRONTEND_TAG="$TAG" \
              docker compose -f docker-compose.prod.yml up -d \
              --force-recreate --no-deps backend frontend

            # Restart nginx
            sudo docker compose -f docker-compose.prod.yml restart nginx

            # Final cleanup
            sudo docker image prune -a -f

## Step 5: Configure GitHub Secrets

Go to your GitHub repository → Settings → Secrets and variables → Actions

Add the following secrets:

DOCKERHUB_USERNAME: Your Docker Hub username
DOCKERHUB_TOKEN: Docker Hub access token
SSH_HOST: Your server IP address or domain
SSH_USER: SSH username
SSH_KEY: Your private SSH key

## Conclusion

You now have a fully automated CI/CD pipeline! Every push to main will automatically build, test, and deploy your application.

Tags: #docker #cicd #githubactions #devops #automation

Questions? Drop them in the comments below! 👇