DEV Community: Darshan R

What Happens When You Upload a File to a Website? Understanding File Uploads

Darshan R — Sun, 23 Aug 2026 09:01:02 +0000

Have you ever uploaded a resume, profile picture, assignment, or PDF to a website?

You choose a file, click Upload, and after a few seconds you see:

✅ Upload successful!

It looks simple from the user's side.

But behind that simple button, the browser, backend, file storage, and database are working together.

So what actually happens when you upload a file?

Let's understand it using a simple example: uploading a resume.pdf to a job website.

The Big Picture

The basic flow looks like this:

Select File
    ↓
Browser
    ↓
FormData
    ↓
HTTP POST Request
    ↓
Backend
    ↓
Validate File
    ↓
Store File
    ↓
Save File Information
    ↓
HTTP Response
    ↓
Upload Complete

Let's understand each step.

1. You Select the File

Suppose a job website asks you to upload your resume.

You select:

resume.pdf

The browser gives JavaScript a File object representing the selected file.

For example:

const file = fileInput.files[0];

console.log(file.name);
console.log(file.size);
console.log(file.type);

You might get:

resume.pdf
245000
application/pdf

A File object is simply JavaScript's representation of the file selected by the user.

At this point, the file has only been selected. It hasn't been uploaded yet.

2. The File Is Put Into FormData

Now we need to prepare the file to send to the backend.

This is where FormData is useful.

Think of FormData like a package containing the information we want to send.

const formData = new FormData();

formData.append("file", file);
formData.append("userId", "42");

Our package now contains:

file   → resume.pdf
userId → 42

So FormData helps us package the file and other form information before sending it.

3. The Browser Sends an HTTP Request

Now JavaScript sends the FormData to the backend.

For example:

fetch("/api/upload", {
    method: "POST",
    body: formData
});

The browser sends a POST request to:

/api/upload

The file is sent using a format called:

multipart/form-data

4. What Is multipart/form-data?

Normally, an HTTP request might contain simple information like:

name = Darshan
email = darshan@example.com

But a file upload contains actual file data along with other fields.

multipart/form-data allows different pieces of data to be sent together in one HTTP request.

For example:

HTTP Request

userId → 42
file   → resume.pdf

So remember:

multipart/form-data is a format used to send files and other form data together in an HTTP request.

5. The Backend Receives the File

The request now reaches the backend.

For example, in a Node.js and Express application, a library such as Multer can process the uploaded file.

A simplified example looks like this:

app.post("/api/upload", upload.single("file"), (req, res) => {
    console.log(req.file);
});

The backend can now access information about the uploaded file.

For example:

filename → resume.pdf
size     → 245 KB
type     → application/pdf

But the backend shouldn't immediately trust the file.

It should validate it first.

6. The Backend Validates the File

The backend should never blindly trust files coming from the browser.

For example, our job website might allow:

PDF
DOCX

But someone might try to upload:

virus.exe

The backend should reject it.

It can check things such as:

File type
File size
File name
Other application-specific rules

For example:

resume.pdf
Size: 2 MB
Type: PDF

      ↓

✅ Valid → Continue

But:

resume.exe
      ↓
❌ File type not allowed

File size limits are also important.

For example:

Maximum allowed size: 5 MB

resume.pdf → 2 MB
      ↓
     ✅

But:

large-video.mp4 → 500 MB
      ↓
     ❌

So:

The backend validates the file before processing or storing it.

7. Where Is the Actual File Stored?

After validation, the application needs to store the actual file.

There are different ways to do this.

For example:

Local server storage
Cloud/object storage

For many modern applications, files such as images, videos, and PDFs are stored in object storage.

The simplified flow is:

resume.pdf
    ↓
Backend
    ↓
File/Object Storage
    ↓
Actual file stored

The important point is that the actual file and its information don't necessarily need to be stored in the same place.

8. What Does the Database Store?

A common beginner question is:

"If the PDF isn't stored directly in the database, how does the application know where it is?"

The database can store metadata about the file.

For example:

files table

id          → 101
user_id     → 42
filename    → resume.pdf
size        → 2 MB
file_url    → /uploads/resume.pdf
uploaded_at → ...

So we can think of it like this:

Actual file
    ↓
File/Object Storage

File information
    ↓
Database

The database stores information that helps the application manage and find the file.

9. The Server Sends a Response

Once the file has been successfully stored and the required information has been saved, the backend sends a response to the browser.

For example:

HTTP/1.1 201 Created

The response might contain:

{
  "message": "File uploaded successfully",
  "fileUrl": "/uploads/resume.pdf"
}

The browser receives the response.

The website can now show:

✅ Resume uploaded successfully!

That's when the user knows the upload is complete.

10. What If Something Goes Wrong?

Uploads don't always succeed.

For example, imagine you upload a 15 MB file while the website allows only 5 MB.

The process might look like:

resume.pdf
   ↓
File size = 15 MB
   ↓
Maximum allowed = 5 MB
   ↓
❌ Upload rejected

The backend might send:

{
  "message": "File size exceeds the limit"
}

The frontend can then show:

❌ Upload failed: File is too large.

The same idea applies if:

The file type isn't allowed.
The request is invalid.
Storage fails.
The server encounters an error.

So the browser needs to handle both success and failure responses.

The Complete File Upload Journey

Let's put everything together.

Imagine you upload:

resume.pdf

The complete journey is:

User selects resume.pdf
          ↓
Browser creates File object
          ↓
File added to FormData
          ↓
POST /api/upload
          ↓
multipart/form-data
          ↓
Backend receives file
          ↓
Backend validates file
          ↓
Actual file stored
          ↓
File metadata saved in database
          ↓
Backend sends response
          ↓
Browser shows upload result

In a real application, the architecture might look like:

                 Browser
                    │
                    │ POST /api/upload
                    ↓
              Backend API
                    │
             ┌──────┴──────┐
             ↓             ↓
       File Storage     Database
       actual file      metadata
             │             │
             └──────┬──────┘
                    ↓
                 Response
                    ↓
                 Browser

A Simple Mental Model

You don't need to memorize every technical term.

Just remember this:

I select a file → the browser creates a File object → puts it into FormData → sends it using an HTTP request → the backend receives and validates it → the actual file is stored → file information is saved in the database → the server sends a response → the browser shows the result.

Or simply:

Select
  ↓
Package
  ↓
Send
  ↓
Validate
  ↓
Store
  ↓
Save Metadata
  ↓
Respond

Final Takeaway

A file upload may look like a single action to the user:

Choose File → Upload

But behind that simple button, several components work together:

Browser
   ↓
HTTP
   ↓
Backend
   ↓
File Storage
   ↓
Database
   ↓
Response

The browser handles the file selection and sends the request.

The backend validates and processes the file.

The actual file can be stored in file/object storage, while the database can store information about that file.

Finally, the backend tells the browser whether the upload succeeded or failed.

The next time you upload a resume, profile picture, or assignment, remember that there's a lot happening behind that simple Upload button.

And that's the basic idea of how file uploads work on the web.

Thanks for reading!

If you're learning web development, don't just use the Upload button.

Try to understand what happens behind it.

What Happens When You Click “Login”? Understanding Authentication for Beginners

Darshan R — Sun, 16 Aug 2026 10:05:31 +0000

You enter your email and password on a website, click Login, and suddenly you're inside your account.

It feels like a simple action.

But what actually happens after you click that button?

How does the website know that the email and password belong to you?

Where does the password go?

How does the server remember that you've logged in?

And how does it know what you're allowed to access?

Let's follow the journey of a login request from the browser to the backend and back.

The Big Picture

Imagine a website with a login form:

Email:    user@example.com
Password: ********

        [ Login ]

You enter your credentials and click Login.

A simplified version of what happens is:

Login Form
    ↓
Browser / JavaScript
    ↓
HTTP Request
    ↓
Backend API
    ↓
Database
    ↓
Password Verification
    ↓
Session / Token
    ↓
HTTP Response
    ↓
User Logged In

Let's break this down using a simple example.

1. You Enter Your Credentials

Suppose you enter:

Email:    sam@example.com
Password: MyPassword123

and click Login.

The browser now has the information that you entered.

But the browser doesn't decide whether the credentials are correct.

The backend needs to verify them.

So the browser sends the login information to a backend endpoint.

2. The Browser Sends a Request

A frontend application might send a request using JavaScript:

fetch("/api/login", {
    method: "POST",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        email: "sam@example.com",
        password: "MyPassword123"
    })
});

The important part here is:

POST /api/login

The browser is basically saying:

"Here are the credentials the user entered. Please process this login request."

The request body might look like:

{
    "email": "sam@example.com",
    "password": "MyPassword123"
}

This request should be sent over HTTPS, so the credentials are protected while traveling between the browser and server.

3. What Is an API Endpoint?

You may have seen URLs such as:

/api/login
/api/users
/api/products
/api/orders

These can be API endpoints.

An API endpoint is a specific location where a client can communicate with a backend operation.

For our login example:

POST /api/login

is the endpoint responsible for handling the login request.

The browser communicates with the backend through this API instead of directly accessing the database.

The architecture can look like:

Browser
   ↓
API
   ↓
Backend
   ↓
Database

The frontend should not directly connect to your database.

4. The Backend Receives the Request

Now the request reaches the backend.

For example, an Express.js application might have something like:

app.post("/api/login", async (req, res) => {
    const { email, password } = req.body;

    // Login logic goes here
});

The backend receives the email and password.

But it should not blindly trust the data coming from the browser.

The server needs to validate it.

5. The Backend Validates the Input

The backend might check:

Is an email provided?
Is a password provided?
Is the email valid?
Are the values in the expected format?

For example, if the user submits:

{
    "email": "",
    "password": ""
}

the server can reject the request.

This is called input validation.

Validation is important because data coming from the client can never be assumed to be trustworthy.

6. The Backend Looks for the User

Suppose the email is:

sam@example.com

The backend needs to find out whether an account with that email exists.

It might query the database:

SELECT id, email, password_hash
FROM users
WHERE email = 'sam@example.com';

The database might return something like:

id: 42
email: sam@example.com
password_hash: $2b$12$...

Notice something important.

The database does not contain:

password: MyPassword123

Instead, it contains a password hash.

Why?

7. Passwords Should Not Be Stored as Plain Text

Imagine a database storing passwords like this:

sam@example.com → MyPassword123

If the database were compromised, attackers could immediately see the users' passwords.

That's why applications should not store user passwords as plain text.

Instead, passwords are processed using dedicated password-hashing algorithms such as:

bcrypt
scrypt
Argon2

The basic idea is:

Password
   ↓
Password Hashing
   ↓
Password Hash
   ↓
Database

The database stores the hash rather than the original password.

8. How Does Password Verification Work?

Now you might wonder:

"If the original password isn't stored, how can the server check whether my password is correct?"

Good question.

When you log in, the server takes the password you entered and uses the password-hashing algorithm to verify it against the stored password hash.

Conceptually:

Password entered by user
          ↓
   Password verification
          ↓
Stored password hash
          ↓
     Match or not?

If the password doesn't match:

Authentication Failed

If it matches:

Authentication Successful

The server does not need to retrieve the original password from the database.

9. Authentication — Who Are You?

This brings us to the main concept of the article:

Authentication.

Authentication means verifying the identity of a user.

When you enter your email and password, the application is essentially asking:

"Are you really the user associated with these credentials?"

If the credentials are correct:

Authentication → Successful

If they aren't:

Authentication → Failed

But authentication is not the same as authorization.

Authentication vs Authorization

These two words are easy to confuse.

Authentication

Who are you?

For example:

Login successful
       ↓
You are Sam

Authorization

What are you allowed to do?

For example:

You are Sam
     ↓
Are you allowed to access /admin?
     ↓
No

So:

Authentication → Who are you?
Authorization  → What can you access?

You can be successfully authenticated but still not have permission to access certain resources.

10. The Server Needs to Remember Your Login

Here's another interesting problem.

HTTP is largely stateless.

That means one request doesn't automatically mean the server remembers everything about previous requests.

Imagine you successfully log in:

POST /api/login

Then you request:

GET /profile

How does the server know that the /profile request belongs to the user who just logged in?

The application needs some way to maintain authentication state.

Two common approaches are:

Session-based authentication
            OR
Token-based authentication

Let's understand both at a high level.

11. Session-Based Authentication

In session-based authentication, the server creates a session after successful login.

The simplified flow is:

User logs in
     ↓
Credentials verified
     ↓
Server creates a session
     ↓
Session ID sent to browser
     ↓
Browser sends session ID with future requests

The browser commonly stores the session identifier in a cookie.

For example:

session_id=abc123

Later, when you request your profile:

GET /profile
Cookie: session_id=abc123

The server can use that session ID to identify the authenticated user.

So the flow becomes:

Browser
   ↓
Session Cookie
   ↓
Server
   ↓
Session
   ↓
User identified

12. What Is a Cookie?

A cookie is a small piece of data that a website can ask the browser to store and send with relevant requests.

Cookies can be used for many things, including:

Login sessions
User preferences
Shopping carts
Other application state

For authentication, a cookie can contain a session identifier.

Security-sensitive cookies are commonly configured with attributes such as:

Secure
HttpOnly
SameSite

These attributes help protect authentication cookies against certain attacks and misuse.

13. Token-Based Authentication

Another approach is token-based authentication.

After a successful login, the server issues a token.

One commonly used token format is JWT (JSON Web Token).

The simplified flow is:

User logs in
     ↓
Credentials verified
     ↓
Server creates token
     ↓
Browser receives token
     ↓
Future requests include token
     ↓
Server validates token

A request might contain:

Authorization: Bearer <token>

The server can validate the token and determine whether the request is authenticated.

One important point:

JWT is a token format, not a synonym for authentication.

Authentication is the overall process of verifying identity.

JWT is simply one technology that can be used to carry authentication-related information.

14. The Server Sends a Response

Once authentication succeeds, the backend sends an HTTP response to the browser.

For example:

HTTP/1.1 200 OK

The response might contain:

{
    "message": "Login successful"
}

The response can also establish authentication state, such as setting a session cookie.

If authentication fails, the server sends an appropriate error response instead.

For example:

Invalid credentials

The frontend can then display an error message to the user.

15. The User Is Now Logged In

After successful authentication, the browser has the information required to make authenticated requests.

For example:

Login
  ↓
Authentication successful
  ↓
Session / Token
  ↓
GET /profile
  ↓
Server identifies user
  ↓
Profile returned

That's why after logging in, you can move between pages without entering your password every time.

The browser keeps sending the relevant authentication information, and the server uses it to recognize the user.

What Happens If the Login Fails?

Let's say Sam enters the wrong password.

The flow becomes:

User enters credentials
        ↓
POST /api/login
        ↓
Backend
        ↓
Find user
        ↓
Verify password
        ↓
Password doesn't match
        ↓
Authentication failed
        ↓
HTTP response
        ↓
Browser shows error

The user might see:

Invalid email or password

The application should also avoid revealing unnecessary information about whether a particular account exists.

The Complete Login Journey

Now let's put everything together.

User enters email + password
            ↓
       Clicks Login
            ↓
     Browser / JavaScript
            ↓
      POST /api/login
            ↓
        Backend API
            ↓
      Validate input
            ↓
     Find user in database
            ↓
    Retrieve password hash
            ↓
     Verify password
            ↓
       ┌───────────────┐
       │               │
     Failed         Successful
       │               │
       ↓               ↓
 Error response    Create session
                       or token
                        ↓
                  HTTP response
                        ↓
                     Browser
                        ↓
               Authenticated user

A simple login button can trigger all of this behind the scenes.

A Simple Mental Model

You don't need to memorize every technical term.

Think of the process as a story:

I enter my credentials → the browser sends them to the backend → the backend validates the request → finds my account → verifies my password → creates authentication state → sends a response → the browser uses that state for future requests.

Or simply:

Login Form
    ↓
POST Request
    ↓
Backend
    ↓
Database
    ↓
Password Verification
    ↓
Session / Token
    ↓
Response
    ↓
Authenticated User

Final Takeaway

The next time you click a Login button, remember that the button itself isn't doing the authentication.

It starts a conversation between several parts of the application:

Browser
   ↓
API
   ↓
Backend
   ↓
Database
   ↓
Authentication
   ↓
Session / Token
   ↓
Browser

The browser collects the credentials and sends a request.

The backend validates the request and checks the user's account.

The password is verified against a stored password hash.

If everything is correct, the application creates some form of authentication state, such as a session or token.

That authentication state allows the server to recognize the user on future requests.

And that's the basic idea behind what happens when you click Login.

Thanks for reading!

If you're learning full-stack development, the next time you click Login, don't just think about the button.

Think about the entire conversation happening behind it.

What Happens When You Type a URL in the Browser?

Darshan R — Sun, 09 Aug 2026 11:12:38 +0000

You type:

https://example.com

into your browser and press Enter.

A few seconds later, the webpage appears.

It feels like the browser simply opened the website.

But behind that simple action, several things happened involving the browser, DNS, IP addresses, HTTP, servers, and browser rendering.

So what actually happens between pressing Enter and seeing the webpage?

Let's follow the journey.

The Big Picture

At a high level, the journey looks like this:

You type a URL
      ↓
    Browser
      ↓
     DNS
      ↓
  IP Address
      ↓
  Connection
      ↓
 HTTP Request
      ↓
    Server
      ↓
HTTP Response
      ↓
 HTML / CSS / JS
      ↓
Browser Rendering
      ↓
  Web Page

Now let's understand what happens at each step.

1. The Browser Starts With the URL

A URL (Uniform Resource Locator) is a string that identifies the location of a resource on the internet and tells the browser how to access it.

For example:

https://example.com/products?id=10

It contains different parts:

https://example.com/products?id=10
   ↓          ↓          ↓        ↓
Protocol    Domain     Path     Query

The https part tells the browser to use secure HTTP communication.

example.com is the domain name.

/products is the path.

?id=10 is a query parameter that provides additional information to the server.

So when you type a URL, you're basically giving the browser an address and instructions for accessing a resource.

But there's a problem.

The browser can't communicate across the internet using just the human-friendly name example.com.

It needs an IP address.

2. DNS Finds the IP Address

This is where DNS (Domain Name System) comes in.

DNS is a system that helps translate domain names into IP addresses.

Think of it like the internet's phonebook.

You remember:

example.com

But the network needs an IP address to identify the destination.

So the simplified process looks like:

example.com
     ↓
    DNS
     ↓
IP Address

An IPv4 address might look like:

93.184.216.34

The actual address returned depends on the website and its DNS configuration.

The browser or operating system may already have the answer cached, so a DNS lookup isn't always required from scratch.

But conceptually, the important idea is:

DNS helps the browser find the IP address associated with the domain name.

Now the browser knows where it needs to communicate.

3. The Browser Connects to the Server

Once the browser knows the destination IP address, it needs to establish a suitable network connection.

A server is a computer or software system that provides resources or services to clients.

In our case:

Browser → Client
Server  → Provides the requested resources

For many traditional web connections, HTTP/1.1 and HTTP/2 use TCP (Transmission Control Protocol) as the transport protocol.

TCP helps provide reliable and ordered delivery of data between applications.

You don't need to memorize the TCP handshake to understand this article.

The simple idea is:

The browser needs a network connection through which it can communicate with the server.

For modern HTTP/3 connections, the transport works differently because HTTP/3 uses QUIC instead of TCP.

For now, the important thing is understanding that the browser needs a suitable connection before exchanging web data.

4. HTTPS Makes the Communication Secure

Our URL starts with:

https://

The S in HTTPS stands for Secure.

HTTPS uses TLS (Transport Layer Security) to protect HTTP communication.

TLS helps provide:

Encryption
Authentication
Integrity

In simple terms, TLS helps protect the communication between your browser and the server and helps the browser verify the server's identity.

A simplified flow is:

Browser
   ↓
Network Connection
   ↓
TLS
   ↓
Secure Communication

Now the browser is ready to communicate with the server securely.

5. The Browser Sends an HTTP Request

Now comes HTTP (Hypertext Transfer Protocol).

HTTP is a protocol that allows clients and servers to communicate on the web.

The browser sends an HTTP request to the server.

For example:

GET /products?id=10 HTTP/1.1
Host: example.com

The browser is essentially saying:

"I want the /products?id=10 resource from example.com."

GET is an HTTP method commonly used when requesting a resource.

An HTTP request can contain things such as:

Method
Path
Headers
Request body, when needed

For our example, the browser is mainly asking the server to retrieve something.

6. The Server Processes the Request

The server receives the request.

Now it has to figure out what to do with it.

For example:

GET /products?id=10

The server might:

Understand the requested path.
Read the query parameter.
Run application logic.
Query a database.
Prepare the required data.
Create a response.

For a simple website, the server might just return an HTML file.

For a dynamic application, there could be much more happening:

Browser
   ↓
HTTP Request
   ↓
Server
   ↓
Application
   ↓
Database
   ↓
Application
   ↓
Server

This is one reason why a simple button click in a web application can trigger many operations behind the scenes.

7. The Server Sends an HTTP Response

After processing the request, the server sends an HTTP response back to the browser.

A response usually contains:

Status code
Headers
Response body

For example:

HTTP/1.1 200 OK
Content-Type: text/html

The response body may contain the HTML for the webpage.

The status code tells the browser the general result of the request.

Some common examples are:

200 → OK
301 → Moved Permanently
302 → Found
400 → Bad Request
401 → Unauthorized
403 → Forbidden
404 → Not Found
500 → Internal Server Error

For example:

200 OK

generally means the request was successfully processed.

If the requested resource doesn't exist, the server might return:

404 Not Found

So the browser now has a response.

But it still has more work to do.

8. The Browser Receives HTML, CSS and JavaScript

The response may contain HTML.

For example:

<!DOCTYPE html>
<html>
<head>
    <title>My Website</title>
</head>
<body>
    <h1>Hello World</h1>
    <p>Welcome to my website.</p>
</body>
</html>

HTML gives the webpage its structure.

HTML → Structure

The HTML may also reference other resources such as CSS, JavaScript, images, and fonts.

For example:

<link rel="stylesheet" href="/style.css">

<script src="/app.js"></script>

<img src="/logo.png">

The browser can then make additional requests to retrieve those resources.

CSS

CSS (Cascading Style Sheets) controls how the webpage looks.

h1 {
    color: blue;
    font-size: 32px;
}

So:

CSS → Appearance

JavaScript

JavaScript adds behavior and interactivity.

For example:

button.addEventListener("click", () => {
    alert("Hello!");
});

So:

JavaScript → Behavior

A simple mental model is:

HTML       → Structure
CSS        → Appearance
JavaScript → Behavior

9. The Browser Builds the Page

Now the browser has to turn all these resources into something you can actually see.

The browser parses the HTML and builds the DOM (Document Object Model).

The DOM represents the webpage as a tree of elements.

For example:

<html>
    <body>
        <h1>Hello</h1>
        <p>Welcome</p>
    </body>
</html>

can be represented conceptually as:

html
└── body
    ├── h1
    │   └── "Hello"
    └── p
        └── "Welcome"

The browser also processes CSS to determine how those elements should look.

It then performs rendering work such as calculating layout and painting the page.

Very roughly:

HTML
 ↓
DOM

CSS
 ↓
Style Information

DOM + CSS
 ↓
Layout
 ↓
Paint
 ↓
Screen

JavaScript may also modify the page or request additional data while the page is loading or after it has loaded.

Finally:

You see the webpage.

So What Actually Happened?

Let's go back to the beginning.

You typed:

https://example.com

and pressed Enter.

Behind the scenes, a simplified version of the journey was:

1. Browser receives the URL
          ↓
2. Browser needs to find the destination
          ↓
3. DNS helps resolve the domain to an IP address
          ↓
4. Browser establishes the required connection
          ↓
5. HTTPS provides secure communication when applicable
          ↓
6. Browser sends an HTTP request
          ↓
7. Server receives and processes the request
          ↓
8. Server sends an HTTP response
          ↓
9. Browser receives HTML and other resources
          ↓
10. Browser processes HTML, CSS and JavaScript
          ↓
11. Browser renders the page
          ↓
12. You see the website

What looked like:

Type URL → Press Enter → Website

was actually closer to:

URL
 ↓
Browser
 ↓
DNS
 ↓
IP Address
 ↓
Connection
 ↓
HTTP Request
 ↓
Server
 ↓
HTTP Response
 ↓
HTML / CSS / JS
 ↓
Browser Rendering
 ↓
Web Page

One More Thing: Real Websites Can Be More Complicated

The flow above is a simplified mental model.

Real-world websites can involve many additional components, such as:

Browser caching
DNS caching
HTTP caching
CDNs
Load balancers
Proxies
APIs
Databases
Cookies
Sessions
Redirects
HTTP/2
HTTP/3
QUIC

For example, a real request might look more like:

Browser
   ↓
DNS
   ↓
CDN / Load Balancer
   ↓
Web Server
   ↓
Application Server
   ↓
Database
   ↓
Response
   ↓
Browser

But you don't need to understand everything at once.

The important thing is to understand the basic journey first.

Final Takeaway

The next time you type a URL and press Enter, remember that the webpage doesn't simply appear from nowhere.

The browser has to find the destination, communicate with the server, request the resource, receive the response, download additional resources, and finally render everything on your screen.

The whole process can be remembered as:

URL
 ↓
DNS
 ↓
IP Address
 ↓
Connection
 ↓
HTTP/HTTPS
 ↓
Request
 ↓
Server
 ↓
Response
 ↓
HTML / CSS / JS
 ↓
Browser Rendering
 ↓
Web Page

A simple action like pressing Enter hides a lot of interesting engineering underneath.

And that's what happens when you type a URL in the browser.

Thanks for reading!

If you're learning web development too, the next time you open a website, don't just look at the page.

Think about the journey that happened before you could see it.

What Happens If a Bank Transfer Fails Halfway? Understanding ACID Properties in SQL

Darshan R — Sun, 02 Aug 2026 14:04:26 +0000

Imagine transferring ₹1,000 from one bank account to another.

Let's say Jeni has ₹10,000 in his account, and Dravid has ₹5,000.

Jeni wants to transfer ₹1,000 to Dravid.

If everything works correctly, two things happen:

₹1,000 is deducted from Jeni's account.
₹1,000 is credited to Dravid's account.

Before the transfer:

Jeni   → ₹10,000
Dravid → ₹5,000

After the transfer:

Jeni   → ₹9,000
Dravid → ₹6,000

Simple, right?

But what happens if something goes wrong halfway through?

Suppose ₹1,000 is successfully deducted from Jeni's account, but before the money is credited to Dravid's account, the application crashes.

Now the database contains:

Jeni   → ₹9,000
Dravid → ₹5,000

Jeni has lost ₹1,000, but Dravid never received it.

That's a serious problem.

In real-world applications, failures can happen because of application errors, system crashes, network failures, or other unexpected situations.

So how do databases prevent operations from being left halfway completed?

That's where database transactions and ACID properties come in.

What Is a Database Transaction?

A database transaction is a logical group of one or more database operations treated as a single unit of work.

Note: This is a simplified example created to explain database transactions. Real banking systems involve additional layers of validation, security, and financial processing.

In our bank transfer example, there are two important operations:

UPDATE accounts
SET balance = balance - 1000
WHERE name = 'Jeni';

UPDATE accounts
SET balance = balance + 1000
WHERE name = 'Dravid';

These two operations belong together.

We don't want the first operation to permanently succeed while the second one fails.

Instead, both operations should succeed together.

A simplified transaction might look like this:

BEGIN;

UPDATE accounts
SET balance = balance - 1000
WHERE name = 'Jeni';

UPDATE accounts
SET balance = balance + 1000
WHERE name = 'Dravid';

COMMIT;

Here, BEGIN starts the transaction, COMMIT permanently saves the changes, and ROLLBACK undoes the changes made by the current transaction if something goes wrong before it is committed.

If something goes wrong before the transaction is successfully completed, its changes can be rolled back:

ROLLBACK;

This prevents the database from being left in an unexpected halfway state.

But what makes transactions reliable?

That's where ACID comes in.

What Are ACID Properties?

ACID represents four important properties of database transactions:

A — Atomicity
C — Consistency
I — Isolation
D — Durability

Instead of memorizing these as definitions, let's understand each one using our bank transfer.

1. Atomicity — All or Nothing

Atomicity means that all operations inside a transaction are treated as one unit.

Either all operations succeed or none of them take effect.

Our bank transfer contains two operations:

Deduct ₹1,000 from Jeni.
Add ₹1,000 to Dravid.

If both operations succeed:

Jeni   → ₹9,000
Dravid → ₹6,000

The transaction can be committed.

But imagine the system crashes after deducting ₹1,000 from Jeni and before crediting Dravid.

Without proper transaction handling, we could end up with:

Jeni   → ₹9,000
Dravid → ₹5,000

Atomicity prevents the transaction from being permanently left in this halfway-completed state.

If the complete transaction cannot succeed, its changes are rolled back.

The accounts return to:

Jeni   → ₹10,000
Dravid → ₹5,000

A simple way to remember Atomicity is:

Everything succeeds, or the transaction doesn't happen.

2. Consistency — Keep the Database Valid

Consistency means that a successful transaction should move the database from one valid state to another while respecting the rules and constraints defined for the data.

Let's look at our simplified bank example.

Before the transfer:

Jeni   → ₹10,000
Dravid → ₹5,000

Total → ₹15,000

After transferring ₹1,000:

Jeni   → ₹9,000
Dravid → ₹6,000

Total → ₹15,000

The money moved from one account to another, but it wasn't magically created or destroyed.

However, consistency is broader than simply keeping the total balance unchanged.

A database may have rules such as:

A balance cannot violate defined constraints.
Required values cannot be missing.
Relationships between records must remain valid.
Data must satisfy the rules defined by the database and application.

A transaction should not leave the database violating these rules.

A simple way to remember Consistency is:

The database should remain valid before and after a transaction.

3. Isolation — Transactions Shouldn't Interfere Unexpectedly

Real applications don't process only one transaction at a time.

Thousands of users may perform operations simultaneously.

Imagine two transactions happening around the same time:

Transaction A:

Jeni transfers ₹1,000 to Dravid.

Transaction B:

Jeni transfers ₹2,000 to Alex.

Both transactions may try to read or modify Jeni's account balance.

Think of it like two people trying to update the same account at the same time. Isolation helps make sure their transactions don't interfere with each other in unexpected ways.

If concurrency isn't handled correctly, one transaction could read an intermediate value or interfere with another transaction's work.

Isolation controls how concurrent transactions can see and interact with each other's changes.

The goal is to prevent unsafe interference and provide predictable results according to the database's isolation guarantees.

Databases can provide different isolation levels, so this doesn't necessarily mean every transaction literally runs one after another.

A simple way to remember Isolation is:

Concurrent transactions should not expose unsafe intermediate states to each other.

4. Durability — Committed Means Saved

Now imagine our transaction completes successfully.

Jeni   → ₹9,000
Dravid → ₹6,000

The database confirms that the transaction has been committed.

Then, one second later, the server crashes.

Should the transfer disappear?

No.

Once a transaction has been successfully committed, Durability means its effects should survive failures such as a system crash.

After the system recovers, the committed information should still be there.

Before the crash:

Jeni   → ₹9,000
Dravid → ₹6,000

After recovery:

Jeni   → ₹9,000
Dravid → ₹6,000

Database systems use mechanisms such as transaction logs and persistent storage to help provide this guarantee.

A simple way to remember Durability is:

Once committed, the result stays committed.

Putting ACID Together

Let's return to the ₹1,000 bank transfer one final time.

Atomicity

The debit and credit should succeed together or be rolled back.

Consistency

The transaction should preserve the rules that define a valid database state.

Isolation

Other transactions should not interfere with the transfer in unsafe ways.

Durability

Once the transfer is committed, its result should survive failures.

Together, these properties help databases execute transactions reliably.

ACID Is Not Just About Banking

Bank transfers are one of the easiest examples for understanding ACID, but transactional reliability is useful in many other systems.

🛒 E-commerce

Placing an order may involve updating inventory, creating an order record, and recording payment-related information.

These related operations may need to succeed together.

🎟️ Ticket Booking

Multiple users may attempt to reserve the same seat at nearly the same time.

Transaction handling helps prevent conflicting operations from producing incorrect results.

📦 Inventory Systems

A purchase may require stock quantities and related records to be updated together.

The system shouldn't reduce stock while failing to create the corresponding order information.

🌐 Social Platforms

Some actions may require multiple related database changes that need to remain consistent.

The exact transaction design and guarantees depend on the application and database being used.

But the underlying problem remains similar:

Related data changes shouldn't leave the system in an unexpected halfway state.

Final Takeaway

When I first came across ACID properties, the four terms could easily look like definitions that simply needed to be memorized.

But they're much easier to understand when we start with a real-world question:

What happens if a bank transfer fails halfway?

That single scenario explains why reliable database transactions are so important.

Atomicity   → All or nothing
Consistency → Keep the database valid
Isolation   → Control concurrent transactions
Durability  → Committed data survives

The next time you transfer money, book a ticket, or place an online order, remember that behind a simple button click there may be multiple database operations that need to work together safely.

And that's exactly the kind of problem database transactions are designed to solve.

If you're learning SQL or databases too, I hope this bank-transfer example made ACID properties a little easier to understand.

Thanks for reading!