DEV Community: Darshan R

One Click. Multiple Systems. One Order.

Darshan R — Sun, 25 Oct 2026 06:55:56 +0000

Imagine you're ordering a pair of shoes for ₹999.

You click Place Order, complete the payment, and wait for confirmation.

A few seconds later, the website shows that your order is confirmed.

Everything looks simple. But what if your payment succeeds and the website never receives the confirmation? What if you click Pay again because the page appears stuck? Could the system charge you twice?

Behind that single click, multiple systems must coordinate to make sure your order is processed correctly.

Let's explore what happens behind the scenes.

What Happens Behind That One Click?

An online purchase involves a website, a backend, a database, and a payment provider.

Here's a simplified view of how the process might work:

Customer Clicks "Place Order"
             ↓
      Backend Processes Request
             ↓
        Order Is Created
             ↓
      Payment Is Requested
             ↓
       Payment Provider
             ↓
        Payment Result
             ↓
      Backend Verifies It
             ↓
       Database Is Updated
             ↓
       Order Is Confirmed

The exact sequence depends on how the application is designed. Payment processing and order confirmation may involve additional steps.

The important part is that a successful payment request doesn't guarantee that every other step will succeed.

Let's look at the problems developers need to solve.

1. Idempotency — What If We Retry?

Imagine you click Pay for your ₹999 shoes.

The payment provider processes your payment successfully, but a network problem prevents your website from receiving the response.

Your website doesn't know whether the payment succeeded or failed.

If it blindly sends another payment request, you could be charged twice.

This is where idempotency becomes important.

Idempotency means that repeating the same operation doesn't repeat its effect.

A payment request can include a unique identifier called an idempotency key.

For example:

pay_order_8472_attempt_1

If the response gets lost, the application can retry the same operation using the same key. A payment provider that supports idempotency can recognize the repeated request and return the original result instead of processing another charge.

The key should be reused for retries of the same operation, not for a genuinely new payment attempt.

The main idea is simple: a missing response doesn't necessarily mean the operation failed.

2. Webhooks — How Does the Website Know?

Now imagine your payment succeeds, but you close the browser before the confirmation appears.

How does your website learn what happened?

Many payment providers support something called a webhook.

A webhook is an HTTP request sent by one system to another when a particular event occurs.

For example, when your payment succeeds, the payment provider can send a notification to your backend.

The backend verifies the notification, identifies the corresponding payment, and processes the necessary updates.

The flow looks like this:

Payment Succeeds
       ↓
Provider Sends Webhook
       ↓
Backend Receives Event
       ↓
Event Is Verified
       ↓
Payment and Order Records Updated

But there's a catch.

A webhook might arrive more than once, arrive late, or fail during processing. That's why the backend needs to verify incoming events and handle repeated notifications safely.

Receiving a notification is only one part of the process. The application must also make sure the event is processed correctly.

3. What If the Payment Succeeds but the Order Doesn't Update?

Let's return to our shoe order.

Your payment provider confirms that your ₹999 payment succeeded. However, the shopping website encounters a database error before updating your order.

The records might now look like this:

Payment provider: SUCCESS
Order database: PENDING

You've paid, but the website still shows your order as pending.

Why does this happen?

The payment provider and the shopping website's database are separate systems. A database transaction can protect related changes inside that database, but it cannot automatically reverse a payment already processed by an external provider.

This connects to the ACID properties we explored in our earlier article about database transactions.

However, keeping one database consistent is different from coordinating multiple independent systems.

So how can the application discover and fix the mismatch?

4. Reconciliation — Finding What Went Wrong

This is where reconciliation becomes useful.

Reconciliation means comparing records from different systems to identify discrepancies.

For example:

System	Status
Payment provider	`SUCCESS`
Order database	`PENDING`

A reconciliation process can identify this mismatch, check the payment provider's records, and safely retry the missing order update.

If the payment status is uncertain, the application should verify it instead of assuming that the payment succeeded or failed.

Reconciliation can run periodically or be triggered by particular failures.

In simple terms, it helps the application discover when its records don't match what actually happened.

What If Something Goes Wrong?

Let's put everything together.

You order your ₹999 shoes. The payment succeeds, but the website temporarily loses the response.

Here's how the application might recover:

Payment Succeeds
       ↓
Response Gets Lost
       ↓
Website Doesn't Know the Result
       ↓
Retry or Check Payment Status
       ↓
Verify the Original Payment
       ↓
Update the Order Safely
       ↓
Confirm the Order

During this process:

Idempotency helps prevent duplicate payment processing when the same operation is retried.
Webhooks communicate payment events to the backend.
Reconciliation helps detect and resolve mismatches when an update fails.

Each mechanism solves a different problem. Together, they help the application handle network failures, duplicate requests, delayed notifications, and database errors.

What I Learned

A single click on a shopping website can trigger operations across several independent systems.

Making those systems work together reliably is more complicated than simply sending a request and receiving a response.

A payment can succeed while the order remains pending. A notification can arrive more than once. A request can time out even though the operation completed successfully.

That's why developers need to think beyond the normal, successful path.

Idempotency helps manage retries. Webhooks communicate events. Reconciliation helps identify and resolve mismatches.

The biggest lesson is that reliable software isn't just about making things work when everything goes right. It's also about handling what happens when things go wrong.

The next time you place an online order, remember that behind that one click, multiple systems must coordinate to make sure the result is correct.

Thanks for reading!

Why Do So Many People Use WhatsApp? Understanding the Technology and Network Effect

Darshan R — Sun, 13 Sep 2026 10:19:44 +0000

Have you ever wondered why so many people use WhatsApp instead of Telegram, Signal, or other messaging apps?

Most people use WhatsApp to send messages, make voice and video calls, share photos, send documents, and communicate through groups.

But WhatsApp became popular for more than just its features. Its success is strongly connected to an important technology and business concept called the network effect.

1. Why Do People Use WhatsApp?

Imagine that you install a new messaging app.

The app has excellent features, beautiful design, and strong privacy. However, none of your friends or family members use it.

What is the use of that app if you cannot communicate with the people you know?

This is one of the main reasons people use WhatsApp.

Many people already use WhatsApp for:

Family conversations
Friends’ groups
College announcements
Office communication
School groups
Business communication
Customer support
Sharing photos, videos, and documents
Voice and video calls

When a person wants to contact someone, they usually choose the app that the other person already uses.

This creates a powerful cycle:

More people use WhatsApp
          ↓
More people can be contacted through WhatsApp
          ↓
More people install WhatsApp
          ↓
Even more people start using WhatsApp

This is called the network effect.

2. What Is the Network Effect?

The network effect means that a product or service becomes more useful when more people use it.

A telephone is a simple example.

If only one person owns a telephone, it is not very useful because there is nobody else to call.

If thousands or millions of people own telephones, the telephone becomes much more valuable.

Messaging apps work in a similar way.

A messaging app becomes more useful when your:

Parents use it
Friends use it
Teachers use it
Colleagues use it
Customers use it
Communities use it

The value of the app is not only in its technical features. Its value also comes from the people available on the platform.

A Simple Example

Suppose you are using WhatsApp and all your friends are also using WhatsApp.

Now, someone recommends Telegram to you.

You install Telegram, but your friends are still using WhatsApp.

You may think:

“Why should I move to Telegram if everyone I want to contact is already on WhatsApp?”

This is why users often stay with a popular messaging app.

3. Why Is It Difficult to Switch Messaging Apps?

Switching to another messaging app is not always technically difficult.

You can download Telegram or Signal in a few minutes.

The real difficulty is convincing everyone else to move with you.

For example:

You install a new messaging app
          ↓
You ask your friends to install it
          ↓
Some friends install it
          ↓
Others continue using WhatsApp
          ↓
You still need WhatsApp

This is sometimes called the network effect problem.

A messaging app is useful only when the people you want to communicate with are also available there.

Therefore, people may continue using WhatsApp even if another app offers different or better features.

4. Is WhatsApp Better Than Telegram or Signal?

Not necessarily.

Different messaging apps focus on different needs.

WhatsApp is widely used for:

Personal messaging
Family and friends’ groups
Voice and video calls
Business communication
Sharing media and documents
Everyday communication

Its biggest advantage is its large user base.

Telegram is known for features such as:

Large groups
Public channels
Bots
Cloud-based message access
Communities and broadcasting

It is useful for people who want to follow channels, communities, and large groups.

Signal

Signal is known for its strong focus on:

Privacy
Secure communication
End-to-end encryption
Minimal data collection compared with many other messaging services

It is useful for people who give high importance to privacy.

The Main Difference

WhatsApp → Large user base and everyday communication

Telegram → Channels, communities, bots, and large groups

Signal → Privacy-focused communication

The best app depends on the user’s needs.

However, WhatsApp benefits from the fact that many people already use it.

5. What Happens When You Send a WhatsApp Message?

Now let’s look at the technical side.

Suppose you send this message to your friend:

“Hey, are you free today?”

The message does not travel directly from your phone to your friend’s phone in a simple straight line.

It passes through a communication system involving networks, servers, and routing.

A simplified flow looks like this:

Your Phone
    ↓
Message Encryption
    ↓
Internet Connection
    ↓
Messaging Service Servers
    ↓
Network Routers
    ↓
Recipient’s Device
    ↓
Message Delivered

Let’s understand each step.

6. Step 1: You Type and Send the Message

You open WhatsApp, select your friend, type a message, and press the Send button.

Your phone prepares the message for transmission.

The application also identifies the intended recipient.

At this stage, the message is still inside your device.

7. Step 2: The Message Is Encrypted

WhatsApp uses end-to-end encryption for personal messages and calls.

End-to-end encryption means that the message is protected while travelling between the sender and the recipient.

In simple terms:

Your Phone → Encrypted Message → Recipient’s Phone

The purpose is to prevent unauthorized people from reading the content of the message while it is being transmitted.

The message is encrypted on the sender’s device and is designed to be decrypted by the intended recipient’s device.

Encryption helps protect the content of the communication. It does not mean that every part of the communication system is invisible.

8. Step 3: The Message Travels Through the Internet

After the message is prepared, it travels through your internet connection.

Your internet connection may be provided by:

Wi-Fi
Mobile data
A broadband connection
Another internet service

The data is divided into small units called packets.

These packets travel through different network devices, including routers.

A router helps forward data towards its destination.

A simplified path looks like this:

Your Phone
    ↓
Wi-Fi Router or Mobile Network
    ↓
Internet Routers
    ↓
Messaging Service Infrastructure

The exact route can change depending on the network conditions.

9. Step 4: Messaging Servers Help Deliver the Message

Messaging services use servers and other backend systems to manage communication between users.

These systems may handle tasks such as:

Identifying the recipient
Managing connections
Temporarily storing messages when necessary
Delivering messages
Handling delivery status
Managing group communication
Supporting media and file transfers
Managing large numbers of users

For example, if your friend is temporarily offline, the service may keep the message available until it can be delivered, depending on the service’s delivery system and policies.

The server does not simply act like a single computer. Large messaging services use distributed systems made up of many machines and services.

10. Step 5: The Message Reaches the Recipient

When your friend’s phone is connected and ready to receive the message, the messaging service attempts to deliver it.

The message reaches your friend’s device, where it can be displayed in the chat.

The overall flow is:

Sender
  ↓
Encrypted Message
  ↓
Internet
  ↓
Messaging Infrastructure
  ↓
Recipient’s Device
  ↓
Message Displayed

This entire process usually happens very quickly.

That is why messaging feels almost instant.

11. What Do the Tick Marks Mean?

WhatsApp uses tick marks to show message status.

In a simplified explanation:

One grey tick: The message has been sent.
Two grey ticks: The message has been delivered.
Two blue ticks: The message has been read, depending on the user’s settings.

These indicators help users understand what happened to their message.

However, message status can depend on settings, network conditions, and the type of conversation.

12. How Can WhatsApp Handle So Many Messages?

A messaging platform must be designed to handle a large number of users and messages.

Imagine millions of people sending messages at the same time.

A single server would not be enough to handle all that traffic.

Large messaging systems use several techniques to improve performance and reliability.

Distributed Servers

Instead of using only one machine, the service can use many servers.

The workload is distributed among these servers.

Many Users
    ↓
Multiple Servers
    ↓
Messages Processed

Load Balancing

Load balancing helps distribute incoming requests across different servers.

This prevents one server from receiving all the traffic while other servers remain unused.

Queues

A queue temporarily holds tasks or messages that need to be processed.

For example:

Incoming Messages
        ↓
Message Queue
        ↓
Processing System
        ↓
Delivery

Queues can help systems manage sudden increases in traffic.

Storage

Messaging services need storage systems to manage information such as:

User accounts
Message-related data
Delivery information
Group information
Media-related information
Settings and preferences

The exact storage design depends on the service and the type of data.

Reliability

Messaging systems must continue working even if some servers or network connections fail.

To achieve this, large systems may use:

Backup systems
Replication
Monitoring
Automatic recovery
Multiple servers
Error handling

The goal is to make communication reliable and available.

13. Why Is Simplicity Important?

Another reason for WhatsApp’s popularity is its simple user experience.

A new user can usually understand the basic process quickly:

Install the App
      ↓
Register Your Number
      ↓
Find Contacts
      ↓
Send a Message

Users do not need to understand servers, routers, encryption, or databases to use the application.

The complicated technology works behind the scenes.

This is an important lesson in software development:

A product can use complex technology internally while providing a simple experience to users.

14. The Real-World Example

Imagine that your college creates a WhatsApp group for students.

The group is used to share:

Exam timetables
Assignment announcements
Important notices
Event details
Class updates

Almost every student joins the group because important information is shared there.

Now, suppose someone creates another messaging group on a different platform.

Students may not join immediately because the important announcements are already available on WhatsApp.

This example shows how the network effect works in real life.

People join a platform because other people and useful information are already there.

15. The Main Lesson

WhatsApp’s popularity is not based on one feature alone.

Its success is connected to several factors:

A large existing user base
Simple communication features
Easy access across devices
Family, college, office, and business usage
Group communication
Media and document sharing
Reliable messaging infrastructure
The network effect

The most important factor is the network effect.

People often choose WhatsApp because the people they want to communicate with are already using it.

Conclusion

WhatsApp is more than a simple messaging application.

From a user’s point of view, sending a message looks easy:

Type → Send → Delivered

Behind the scenes, the process involves:

Encryption
    ↓
Internet Networks
    ↓
Routers
    ↓
Servers
    ↓
Message Processing
    ↓
Recipient’s Device

Its widespread adoption also demonstrates the power of the network effect.

Telegram, Signal, and other messaging apps may offer valuable features, but users often stay with WhatsApp because their friends, families, colleges, offices, and communities are already there.

The biggest lesson is:

A product becomes more useful when more people use it. This is the power of the network effect.

Thanks for reading!

What Happens When You Refresh a Web Page? Understanding Browser Cache for Beginners

Darshan R — Sun, 30 Aug 2026 11:07:55 +0000

Have you ever noticed that a website sometimes loads slowly the first time, but much faster when you visit it again?

For example, imagine you open an online shopping website for the first time.

The browser needs to download things like HTML, CSS, JavaScript, images, and fonts.

After the page loads, you refresh it.

Suddenly, the page may load much faster.

So what happened?

The answer is browser caching.

What Is Browser Cache?

A browser cache is temporary storage used by your browser to keep copies of certain resources from websites.

Think of it like keeping frequently used things at home instead of going to the store every time you need them.

For example, a website might contain:

style.css

app.js

logo.png

font.woff2

The browser can store some of these resources in its cache.

So when you visit the website again, the browser may be able to reuse them instead of downloading everything again.

What Happens When You Visit a Website for the First Time?

Let's say you visit example.com.

The browser requests the resources needed to display the page.

The simplified flow is:

Browser → Server → HTML, CSS, JavaScript, Images → Browser → Display Page

While receiving these resources, the browser may store some cacheable resources locally.

For example:

Browser Cache → style.css, app.js, logo.png

Now the browser has some resources available for future use.

What Happens When You Refresh?

Now you press Refresh 🔄.

The browser doesn't always download everything again.

Instead, it can check whether cached resources can still be used.

The simplified process is:

Refresh Page → Browser Checks Cache → Can Cached Resource Be Reused?

If yes, the browser may use the cached resource.

If not, it may request the resource again from the server.

This can make websites feel much faster.

Does Refresh Always Use the Cache?

Not necessarily.

The browser follows caching rules provided by the website.

The server can tell the browser how a resource should be cached using HTTP response headers.

One important header is Cache-Control.

For example:

Cache-Control: max-age=3600

This tells the browser that the resource can generally be considered fresh for a certain amount of time.

So caching isn't simply:

"If I downloaded it once, always use it."

The browser follows rules to decide whether a cached resource can be reused or needs to be checked again.

What Is ETag?

Another useful concept is ETag.

An ETag is a value that helps the browser and server determine whether a resource has changed.

Imagine the browser previously downloaded app.js.

The server provided an ETag for that version.

Later, the browser can ask the server whether that version is still current.

If the resource hasn't changed, the server can respond with:

304 Not Modified

This means the browser can continue using its cached copy.

If the resource has changed, the server can send the newer version.

The basic idea is:

Browser has cached file → Checks with server → Has it changed?

No → Use cached copy

Yes → Download the new version

What Happens When You Press Ctrl + R?

When you press Ctrl + R, you're performing a normal reload.

The browser still follows the relevant caching rules while loading the page.

It doesn't necessarily mean:

"Delete everything and download everything again."

That's an important distinction.

What About Ctrl + Shift + R?

You may have noticed another shortcut:

Ctrl + Shift + R

This is commonly used for a hard reload.

It asks the browser to reload the page while being more aggressive about bypassing cached resources.

Developers often use it when they've changed CSS or JavaScript but the browser appears to be showing an older version.

For example:

You update style.css → Refresh → Old CSS may still appear → Hard Reload → Browser fetches the latest resources

The exact behavior can vary by browser and situation, but the main idea is that a hard reload is useful when you want to avoid relying on cached resources.

Why Is Browser Caching Useful?

Caching provides several benefits.

Faster Loading

Previously cached resources may not need to be downloaded again.

Less Network Usage

The browser may reuse local resources instead of downloading them repeatedly.

Better User Experience

Pages can feel faster, especially when returning to a website.

For example:

First Visit → Download Resources → Cache Them

Second Visit → Reuse Available Resources → Page May Load Faster

But Caching Can Cause Problems Too

Imagine you're a developer.

You update your website's CSS.

Old CSS → New CSS

But a user still sees the old design.

Why?

Their browser might still have an older cached version of the CSS.

This is one reason developers sometimes use techniques such as cache busting or versioned filenames.

For example:

app.v1.js

Later:

app.v2.js

Because the filename changed, the browser treats it as a different resource and requests the new file.

A Simple Real-World Example

Imagine you visit a news website for the first time.

The browser downloads the HTML, CSS, JavaScript, images, and other resources needed to display the page.

Some of these resources may be stored in the browser cache.

Later, you refresh the page.

The browser checks its cache and the website's caching rules.

If a resource can still be reused, the browser may use the cached copy.

If a resource needs to be updated, the browser requests it again.

So the simplified flow is:

First Visit → Download Resources → Store Cacheable Resources

Refresh → Check Cache → Reuse What Can Be Reused → Fetch What Needs Updating → Display Page

That's why a page can sometimes load faster after the first visit.

The Complete Picture

So what happens when you refresh a web page?

The simplified process is:

You click Refresh → Browser starts loading the page → Browser checks cached resources → Caching rules are considered → Reusable resources may come from cache → Changed or expired resources may be requested → Server sends responses when needed → Browser combines the resources → Page is displayed

A Simple Mental Model

You don't need to memorize every caching term.

Just remember:

First visit: The browser downloads resources and may store some of them in the cache.

Refresh: The browser checks whether cached resources can still be reused.

If reusable: The browser may use the cached copy.

If outdated: The browser may request an updated version.

That's the basic idea behind browser caching.

Final Takeaway

Browser caching is one of those things we use every day without thinking about it.

When you visit a website, your browser may store resources such as CSS, JavaScript, images, and fonts.

When you return or refresh the page, the browser can reuse those resources when the caching rules allow it.

This helps websites load faster and can reduce unnecessary network requests.

The next time you press Refresh, remember:

The browser isn't necessarily starting from zero. It may already have some of the resources the page needs.

And that's the basic idea behind browser caching. 🚀

Thanks for reading!

If you're learning web development, understanding what happens behind everyday browser actions can help you build a much stronger foundation.

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 ₹5,000 from one bank account to another.

Let's say Jeni has ₹25,000 in his account, and Dravid has ₹15,000.

Jeni wants to transfer ₹5,000 to Dravid.

If everything works correctly, two things happen:

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

Before the transfer:

Jeni   → ₹25,000
Dravid → ₹15,000

After the transfer:

Jeni   → ₹20,000
Dravid → ₹20,000

Simple, right?

But what happens if something goes wrong halfway through?

Suppose ₹5,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   → ₹20,000
Dravid → ₹15,000

Jeni has lost ₹5,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 - 5000
WHERE name = 'Jeni';

UPDATE accounts
SET balance = balance + 5000
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 - 5000
WHERE name = 'Jeni';

UPDATE accounts
SET balance = balance + 5000
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 ₹5,000 from Jeni.
Add ₹5,000 to Dravid.

If both operations succeed:

Jeni   → ₹20,000
Dravid → ₹20,000

The transaction can be committed.

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

Without proper transaction handling, we could end up with:

Jeni   → ₹20,000
Dravid → ₹15,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   → ₹25,000
Dravid → ₹15,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   → ₹25,000
Dravid → ₹15,000

Total → ₹40,000

After transferring ₹5,000:

Jeni   → ₹20,000
Dravid → ₹20,000

Total → ₹40,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 ₹5,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   → ₹20,000
Dravid → ₹20,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   → ₹20,000
Dravid → ₹20,000

After recovery:

Jeni   → ₹20,000
Dravid → ₹20,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 ₹5,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!