DEV Community: Mandar Gokhale

Helping a friend connect his BigRock domain to Cloudflare pages

Mandar Gokhale — Fri, 22 Aug 2025 18:48:48 +0000

A friend of mine needed a simple one-page website for his business. Nothing fancy — just something professional that could go live quickly. I figured Cloudflare Pages was the best option: free hosting, blazing-fast CDN, and automatic SSL.

I knew the basics: if I could point the domain from BigRock to Cloudflare using CNAMEs, we’d be in business. At least, that’s what I thought.

BigRock’s Old vs New UI Problem

The first hurdle was BigRock’s interface. They have an “old” UI and a “new” UI — and they don’t behave the same way.

In the old UI, I could actually delete BigRock’s default nameservers and replace them with Cloudflare’s nameservers (as required).
In the new UI, the old nameservers kept showing alongside the new ones, which was confusing.

So if you’re stuck, pro tip: use the old BigRock UI to make clean changes to nameservers.

Domain Mapping and CNAME Setup

Once the domain was delegated to Cloudflare, the next step was setting up DNS records inside Cloudflare. This is where the domain mapping happens — it’s how your friendly business domain (example.com) gets connected to the special .pages.dev address Cloudflare Pages gives you.

The correct setup looks like this:

Type	Name	Target (Content)	Proxy
CNAME	`@`	`<your-project>.pages.dev`	Proxied (orange cloud)
CNAME	`www`	`<your-project>.pages.dev`	Proxied (orange cloud)

@ represents the root domain (example.com).
www is the subdomain (www.example.com).
Both must point to the Cloudflare Pages project’s .pages.dev domain.

This part I got right — but the site still wouldn’t load.

Debugging with `dig`

After switching nameservers and adding CNAMEs, I expected things to work right away. But no — the website kept throwing gateway timeouts and later 522 errors.

That’s when the dig command became my best friend:

dig www.example.com CNAME

This command showed me whether the DNS records were actually resolving. For a long time, dig returned nothing, which told me the changes hadn’t propagated or weren’t set correctly.

The Missing Piece: Custom Domains in Cloudflare Pages

Here’s the part that tripped me up the most.

Even though I had the CNAME records pointing correctly, I didn’t realize that Cloudflare Pages also requires you to register the domain inside the project itself.

To fix this:

Go to Cloudflare → Workers & Pages → Your Pages Project → Custom Domains.
Add both the root domain (example.com) and the www domain (www.example.com).
Cloudflare then validates the DNS setup and issues SSL certificates.

Until you do this, you’ll keep getting 522 errors, because Pages doesn’t yet know the domain belongs to your project.

SSL and the Final Wait

Once I finally added the custom domains in Cloudflare Pages, everything clicked into place. DNS validated, Cloudflare started issuing SSL, and after 10–30 minutes the status showed Active.

My friend’s one-page site was finally live on his BigRock domain — fast, secure, and free.

What I Learned

BigRock UI quirks: sometimes only the old UI lets you remove their default nameservers.
CNAMEs are essential: you must map both root and www to your Pages project’s .pages.dev domain.
dig is your friend: it confirms if DNS is actually resolving.
Custom Domains in Pages are required: DNS records alone are not enough.
SSL takes time: don’t panic if you see errors while it’s still provisioning.

Common Errors & Fixes

Gateway Timeout (504 / 522) → Usually means your CNAME records are missing or incorrect. Make sure both root and www point to your Pages project.
Error 522 after CNAMEs are correct → You likely forgot to add the domain inside Cloudflare Pages → Custom Domains. Add both root and www.
SSL Pending or Invalid Certificate → Normal after adding a custom domain. Wait 10–30 minutes; Cloudflare will provision SSL automatically.
Old Nameservers Still Showing → Use BigRock’s old UI to delete default nameservers, and wait for propagation (24–48 hours). Confirm with dig or dnschecker.org.
Site works on www but not root (or vice versa) → Add a redirect rule in Cloudflare so one version forwards to the other (better for SEO).

Why I’ll Use Cloudflare Pages Again

Despite the confusion, Cloudflare Pages is a fantastic platform:

No servers to manage.
Free global CDN and SSL.
Smooth Git integration for deployments.

Now that I know the “gotchas” — BigRock’s UI quirks, CNAME domain mapping, and the hidden Custom Domains step — the process is much smoother.

And most importantly: my friend’s site is online, looking professional, and loading fast.

Isolation — The Trickiest ACID Pillar (And Why It Matters More Than You Think)

Mandar Gokhale — Sun, 25 May 2025 10:56:42 +0000

When I first started diving into ACID properties, I thought I had them figured out. Atomicity? Sure, all-or-nothing makes sense. Consistency? Yeah, keep your data valid. Durability? Of course, don't lose my writes. But Isolation?

That one had me scratching my head.

The textbook definition was simple enough:

"Each transaction should run as if it's the only one in the system."

But what does that actually look like? I kept staring at this definition thinking, "Okay, but how do you even see that happening?" I couldn't visualize it, so naturally, I went down a rabbit hole.

💡 The "Aha!" Moment: It's Not Black and White

Here's what clicked for me: isolation isn't just "on" or "off." There's actually a whole spectrum of isolation behaviors, and databases let you pick your poison through something called Isolation Levels.

Picture this scenario that made it all clear for me:
You're halfway through generating a payroll report. You've started reading employee salaries when—plot twist—someone else adds a brand new employee to the system.

Will your report include that new person or not?

My first instinct was "Well, it depends on timing, right?" But that's when I realized: It depends on the isolation level you choose.

That's when it hit me—I wasn't just learning what isolation was; I needed to understand all the different flavors of isolation that databases actually offer. So I started exploring them one by one, and each level taught me something new about the trade-offs involved.

🗺️ My Tour Through the Isolation Levels

Let me walk you through how I understood each level—not through boring charts, but through the stories and examples that made them click for me. I'll start from the most relaxed level and work up to the strictest.

1️⃣ Read Uncommitted: "I'll Take Whatever You've Got" 📥

"Show me anything, even if it's not officially saved yet."

When I first read about this level, my reaction was: "Wait, you can read data that might disappear? That sounds insane!"

This level lets you read data that other transactions haven't even committed yet. So you might read something that gets rolled back moments later. These are called dirty reads, and they sound as messy as they are.

Here's what freaked me out initially:

-- Transaction A starts transferring money
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE name = 'Alice';
-- Alice's balance is now -500, but not committed yet

-- Transaction B peeks at the data
SELECT balance FROM accounts WHERE name = 'Alice';
-- Reads -500, even though A might roll back!

My first thought: "Who would ever want this madness?"

But then I found a use case that actually made sense. Imagine you're building a real-time dashboard showing server metrics. The numbers update every second, and you care more about seeing the latest trend than getting every single digit perfect.

SELECT AVG(cpu_usage) FROM metrics WHERE timestamp > NOW() - INTERVAL '5 minutes';

Even if some writes get rolled back, you just want the most current signal. You're trading accuracy for speed—and sometimes that's exactly what you need.

It's still risky as hell, but when used intentionally? It can be the right call.

2️⃣ Read Committed: The Sensible Default ✅

"Only show me the official, committed stuff."

This one felt like the Goldilocks zone to me—not too loose, not too strict. It ensures you only see data that's been properly committed. No more dirty reads, no more reading stuff that might vanish.

That's why it's the default in PostgreSQL and MySQL. It just makes sense for most situations.

But here's where I got my next surprise:

-- I start a transaction
BEGIN;
SELECT balance FROM accounts WHERE name = 'Alice';
-- Returns 1000

-- Meanwhile, someone else updates Alice's balance
UPDATE accounts SET balance = 4000 WHERE name = 'Alice';
COMMIT;

-- I read again in the same transaction
SELECT balance FROM accounts WHERE name = 'Alice';
-- Now returns 4000. Wait, what?

Even though I avoided dirty reads, the data could still change between my reads—this problem is called a non-repeatable read. But Read Committed also doesn't protect against another subtle issue I discovered: phantom reads.

😵‍💫 Wait, What’s a Phantom Read?

This concept had me confused for a while, so let me explain it the way it finally clicked for me:

Phantom Read = New rows magically "appear" when you repeat the same query within your transaction.

-- I start looking at the sales team
BEGIN;
SELECT * FROM employees WHERE department = 'Sales';
-- Results: Alice, Bob, Carol (3 people)

-- Meanwhile, HR adds someone new
INSERT INTO employees VALUES ('David', 'Sales');
COMMIT;

-- I run the exact same query again
SELECT * FROM employees WHERE department = 'Sales';  
-- Results: Alice, Bob, Carol, David (4 people)
-- David is the "phantom"—he wasn't there before!

It's called "phantom" because these new rows appear like ghosts—they weren't there when you first looked, but suddenly materialize out of thin air.

This got me thinking: when would this actually matter?

3️⃣ Repeatable Read: "I Want Consistency, Dammit!" 🔁

"Give me the same data every time I look."

Initially, I couldn't figure out when I'd need this. I mean, if I'm just grabbing payroll data for April 2025:

SELECT * FROM payroll WHERE pay_month = '2025-04';

This should give me consistent results, right? Why would I need something stronger?

Then it hit me: this is about long-running transactions. Not your quick 100ms queries, but operations that take minutes or hours.

💡 The Lightbulb Moment: Audit Reports

Imagine generating a regulatory audit report for all transactions on January 15th. This beast takes 30+ minutes and touches multiple tables:

BEGIN; -- Using Repeatable Read

-- Step 1: Get summary totals
SELECT SUM(debit) FROM transactions WHERE date = '2025-01-15';
SELECT SUM(credit) FROM transactions WHERE date = '2025-01-15';

-- Step 2: Count failures
SELECT COUNT(*) FROM failed_transactions WHERE date = '2025-01-15';

-- Step 3: Detailed breakdown (this takes forever)
SELECT account_id, SUM(amount) FROM transactions WHERE date = '2025-01-15'
GROUP BY account_id;

If someone inserts a new transaction with the same date while I'm running this, my summary totals won't match my detailed breakdown. The whole report becomes garbage.

Repeatable Read saves the day by giving me a consistent snapshot for the entire duration. No phantom reads, no surprises—just the same view of data from start to finish.

👁️ Another Eye-Opener: Clinical Research

Here's another scenario that really drove the point home for me. Imagine you're analyzing data from a clinical trial—this stuff is serious, lives depend on getting it right:

-- Clinical trial analysis - data consistency is critical
BEGIN;
SELECT AVG(blood_pressure) FROM patients WHERE treatment = 'drug_a';
SELECT AVG(blood_pressure) FROM patients WHERE treatment = 'placebo';
SELECT COUNT(*) FROM adverse_events WHERE treatment = 'drug_a';
-- Multiple statistical calculations that take hours...

If patient data gets updated while you're crunching these numbers—maybe new test results come in, or adverse events get recorded—your statistical conclusions become completely invalid. You might conclude that Drug A is safer than it actually is, or vice versa.

In research, temporal consistency isn't just nice to have—it's legally required. Your analysis must be based on a single, coherent snapshot of the data, or regulatory bodies will throw it out.

This is huge for:

Financial audits where numbers must add up perfectly
Scientific research where data consistency affects validity and regulatory approval
Risk analysis where inconsistent snapshots lead to catastrophically bad decisions

Most web apps don't need this level of protection, but when you do? There's absolutely no substitute.

4️⃣ Serializable: "No Funny Business Allowed" 🚫

"Make it behave like transactions run one at a time, period."

This is the nuclear option—the highest isolation level that guarantees transactions behave as if they ran sequentially, even though they're actually concurrent.

I thought Repeatable Read was strict, but Serializable prevents an even more subtle problem that blew my mind: write skew.

😷 The Hospital Shift Nightmare

This example made write skew crystal clear for me. Imagine a hospital scheduling system with one critical rule: "At least one doctor must be on duty at all times."

Right now, there are exactly 2 doctors scheduled for tonight: Dr. Alice and Dr. Bob.

-- Transaction A: Dr. Alice wants time off
BEGIN;
SELECT COUNT(*) FROM shifts 
WHERE date = '2025-05-25' AND shift = 'night';
-- Returns: 2 doctors
-- Alice thinks: "2 - 1 = 1 remaining, I can take time off!"

-- Transaction B: Dr. Bob wants time off (running at the same time!)
BEGIN;
SELECT COUNT(*) FROM shifts 
WHERE date = '2025-05-25' AND shift = 'night';
-- Returns: 2 doctors  
-- Bob thinks: "2 - 1 = 1 remaining, I can take time off too!"

-- Both update different rows
UPDATE shifts SET status = 'time_off' WHERE doctor = 'Alice' AND date = '2025-05-25';
UPDATE shifts SET status = 'time_off' WHERE doctor = 'Bob' AND date = '2025-05-25';
COMMIT; COMMIT;

Result: Both doctors got approved for time off. The night shift now has zero doctors. The hospital's critical rule just got violated!

This is write skew—both transactions read the same data, made logical decisions, but their combined effect created chaos. Traditional row locking wouldn't catch this because they modified different rows.

Serializable isolation would detect this conflict and abort one transaction. When the unlucky doctor retries, they'd see only 1 doctor scheduled and get their request denied. Crisis averted.

🦸‍♂️ When You Actually Need This Superpower

Banking: Preventing family accounts from going below minimum balances
Healthcare: Ensuring minimum staff coverage (like our hospital example)
Inventory: Preventing overselling when stock is critically low
Any system where business rules span multiple rows or tables

The trade-off? Performance takes a hit because more transactions get aborted and retried. But when you need bulletproof consistency? It's the only game in town.

📚 What This Journey Taught Me

Digging into isolation levels wasn't just about learning database theory—it completely changed how I think about concurrent systems:

Isolation is sneaky powerful. Those subtle bugs that only happen under load? Often isolation issues.
Different problems need different solutions. There's no one-size-fits-all isolation level.
Most importantly: Just because your data is committed doesn't mean it's consistent from a business logic perspective.

If you've ever wondered why building reliable concurrent systems is hard, isolation is a big part of the answer. But once you understand the levels and their trade-offs, you can make informed decisions instead of just hoping for the best.

💬 Have you run into weird concurrency bugs that disappeared when you cranked up the isolation level? I'd love to hear your war stories in the comments!

Atomicity – The "All or Nothing" Magic Behind Database Transactions

Mandar Gokhale — Tue, 20 May 2025 09:08:56 +0000

In Part 1, we explored the four pillars of ACID: Atomicity, Consistency, Isolation, and Durability. But let's be honest — concepts like these can feel a bit textbook-ish until you hit a real problem and think, "Wait, how does this work under the hood?"

That's exactly what happened to me.

I found myself wondering:
How does the database make sure I don't end up with half-finished data?

That question led me to discover one of the most fascinating pieces of database architecture:
Atomicity, and its behind-the-scenes hero — the Write-Ahead Log (WAL).

💥 The Banking Disaster That Never Happened

Let's re-look at a simple example: you're transferring ₹100 from Alice to Bob.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 100 WHERE name = 'Bob';
COMMIT;

Looks clean, right?

But what if the server crashes right after debiting Alice, before Bob gets anything?

😱 Alice loses money. Bob gets nothing. Nobody wins.

That's where atomicity steps in — the database's promise that either everything happens or nothing does. No half-cooked data, no side effects.

But how?

🔍 Peeking Behind the Curtain: Write-Ahead Logging

One might think that databases simply update data files directly—just write to disk and it's done.

Turns out, that would be a disaster during a crash. It's like scribbling on a paper while someone's shaking the table — good luck keeping it neat.

Instead, databases use a strategy that's equal parts paranoid and brilliant:
Write down your plans first, then act.

That's the Write-Ahead Log (WAL). It's like the database's diary:

Heres exactly what I'm going to do. If I get interrupted, I'll just retrace my steps.

⚒️ How It Works?

Here's what really happens when you run a transaction:

You start the transaction.
The database logs every change — not to the table, but to the WAL.
When all the changes are logged, the WAL is flushed to disk.
Only then does the database respond with COMMIT successful.
The actual table data? That might get updated later.

Yes — the real data might still be unchanged after your transaction commits. Mind-bending, right? This completely flipped my understanding. I always thought COMMIT meant "okay, it's definitely written to the database now." But really, it means "I've made an unbreakable promise to write it, and I have the receipt to prove it."

💡 When Does the Actual Data Get Updated?

This puzzled me at first. I assumed "commit" meant the database had written the final result.

But really, the WAL is the source of truth. As long as those logs are safe, the database can recreate the transaction later.

If the server crashes before it updates the real data? No problem. On restart, it reads the WAL and says:

Hmm, looks like I promised to credit Bob ₹100. Let me go finish that now.

It's like waking up and checking your to-do list: "Oh right, I never did step two."

🔄 Flushing the WAL – What Does That Really Mean?

Here's where I hit another wall.

Everyone says "WAL is flushed to disk" but what does that actually mean?

Turns out, it's a three-step process:

The WAL is written to an in-memory buffer.
The OS queues that buffer to be written to the disk.
The database calls fsync() (or equivalent) to say:

"No, don't just promise to write it. Physically write it now."

That last step is critical. Without it, your data could still be floating around in memory buffers, and a power cut would wipe it out.

🗂️ What Happens After the WAL is Applied?

Okay, so the transaction is written to the WAL file… and later, it's applied to the actual database. But then what?

Does the WAL file get deleted?
Is the entry removed after the transaction is committed?

Not immediately.

In most databases—like PostgreSQL—the WAL (Write-Ahead Log) files are retained even after the changes they describe have been applied to the data files.

Why?

Because they serve more purposes than just crash recovery:

🔄 They support replication to standby servers
📂 They're used for point-in-time recovery (PITR)
📦 They can help with logical decoding and incremental backups

The database maintains checkpoints to track which changes have been fully flushed to disk. Once it's sure that:

All data changes described in the WAL are safely written to disk, and
The WAL is no longer needed for replication or recovery...

...then, and only then, the old WAL segments are marked for removal or archiving, depending on your settings.

So yes, even after a transaction is committed, the WAL entry sticks around for a while, unless you're in a minimalist config.

🤔 Okay, Hold On — If WAL is kept around, won't it apply the same transaction twice if the DB crashes again and again?

This was my next big question.

If WAL is replayed after a crash, how does the database avoid applying the same changes more than once?

The answer: LSNs — Log Sequence Numbers.

Each WAL record has an LSN. Every data page also stores the LSN of the last WAL entry it applied.

During recovery:

If the WAL's LSN > page's LSN → apply
If not → skip it, it's already done

It's like the database saying, "Oh, I already covered this. Moving on."

🔁 The Crash Recovery Sequence

Let's put it all together:

You run transaction #101. WAL gets written.
COMMIT is issued. WAL is flushed to disk.
💥 Crash! Data pages never got updated.
Database restarts. Sees WAL for TX 101.
Applies the changes — based on LSNs.
Done. The system is back where it was, no data lost.

That's atomicity in action. Clean, recoverable, foolproof.

❌ What WAL Doesn't Do

Here's something I misunderstood for a while:

WAL doesn't enforce constraints or business logic.

If you try to transfer ₹10,000 from an account that only has ₹5, the database rejects the transaction — before it ever touches the WAL.

WAL's job starts after the transaction passes all checks.

So:

Atomicity is: "Apply all-or-nothing"
Consistency is: "Only valid transactions are allowed"

Mixing those two up is easy — but important to separate.

🧪 PostgreSQL vs MySQL: WAL in the Wild

Different databases use different flavors of WAL:

✅ PostgreSQL

Redo log only — applies committed changes during recovery
Background process updates actual data files
Controlled with synchronous_commit setting

✅ MySQL (InnoDB)

Uses both redo and undo logs
Redo = for committed transactions (like PostgreSQL)
Undo = for rolling back partial changes
Controlled with innodb_flush_log_at_trx_commit

🧠 Why This Actually Matters (No, Really)

If you think COMMIT is just a magic spell that makes your data safe — think again. Understanding WAL flips the script:

💣 Stop with the micro-transactions — every COMMIT slams a WAL flush. Your database isn’t a vending machine.
🧩 Bundle your writes — batch related changes into one clean, atomic move. It’s not just tidy — it’s smart.
⚠️ Delayed durability? That’s code for “please lose my data if something crashes.” Use with extreme caution.
🔍 Know what COMMIT actually does — it's not fairy dust. It’s a disk write, a sync, and a promise. Respect it.

Treat your transactions like they matter — because they do.

📌 TL;DR

Question	Answer
What is WAL?	A durable log of all pending transaction ops
When is a transaction "committed"?	After WAL is flushed to disk (`fsync`)
What if we crash after commit?	WAL is replayed — data is recovered
Can WAL be applied twice?	No — LSNs prevent duplicate application
Does WAL enforce data validity?	No — it only logs valid transactions

🕒 Next Up: Isolation

Now that we've uncovered the "A" in ACID, it's time to dive into the most slippery one — Isolation.

In Part 3, we'll explore:

What really happens when two users update the same data at the same time
The difference between repeatable read and serializable
And what a "phantom read" actually looks like

I promise — it's weirder and more fun than it sounds.

Rediscovering ACID – The Foundation of Reliable Databases

Mandar Gokhale — Sun, 18 May 2025 10:42:25 +0000

As engineers, we use transactions all the time — BEGIN, COMMIT, and maybe a rollback if things go south. But recently, I realized I hadn’t truly internalized what makes those transactions reliable.

That curiosity led me to revisit the ACID properties — a foundational concept we all learn early on but rarely pause to deeply understand. What started as a quick refresher turned into a deep dive into atomicity, consistency, isolation, and durability, and how real databases like PostgreSQL and MySQL implement them.

Along the way, I discovered that one core mechanism — the Write-Ahead Log (WAL) — is key to both Atomicity and Durability, playing a foundational role in keeping transactions safe and recoverable.

In this first part of a multi-part series, I’ll walk through what each property means, why it matters, and where it shows up in real-world systems. We'll ground the theory with SQL examples you can run yourself.

🔹 What is ACID?

ACID stands for:

Atomicity – All or nothing
Consistency – The database moves from one valid state to another
Isolation – Transactions don’t interfere with each other
Durability – Once committed, data is forever

Let’s look at each one with practical examples.

🧱 Atomicity – All or Nothing

A transaction must either complete entirely or not at all.

Imagine transferring ₹100 from Alice to Bob:

Debit Alice. Credit Bob. If only one of those happens, the system is in a bad state.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE name = 'Alice';
-- crash happens here
UPDATE accounts SET balance = balance + 100 WHERE name = 'Bob';
COMMIT;

Since COMMIT never happened, PostgreSQL will rollback the entire transaction automatically.

📐 Consistency – Enforcing Rules

A database should always transition from one valid state to another. That includes enforcing:

Constraints
Data types
Foreign keys
Application invariants

✅ Example 1: Check constraint

ALTER TABLE accounts ADD CONSTRAINT check_balance CHECK (balance >= 0);

BEGIN;
UPDATE accounts SET balance = balance - 5000 WHERE name = 'Alice';
COMMIT; -- ❌ rejected if Alice only has ₹1000

✅ Example 2: Foreign key constraint

CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name TEXT
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INT REFERENCES customers(id)
);

-- ❌ This fails
INSERT INTO orders (customer_id) VALUES (999);

PostgreSQL blocks the insertion because customer 999 doesn’t exist.

ℹ️ Note:

The database does not define consistency on its own — it simply enforces the rules you define.
If your schema or application logic doesn't include constraints, the database won't protect them automatically.

🔒 Isolation – Transactions Don’t Bump Into Each Other

This is the most subtle — and arguably the most important — part of ACID. Isolation means each transaction should act like it’s the only one running, even in a highly concurrent system.

Databases offer multiple isolation levels to balance correctness and performance:

Read Uncommitted
Read Committed
Repeatable Read
Serializable

In upcoming part, we’ll go deep into isolation levels, MVCC, and real-world concurrency bugs.

💾 Durability – Survives Crashes

Once you COMMIT, it’s permanent — even if the database crashes 1ms later.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 100 WHERE name = 'Bob';
COMMIT;

How is that possible? That’s what we’ll explore in detail in Part 2 — where we discuss WAL (Write-Ahead Logging).

🧠 Coming Up Next

In the next post, we’ll dive into how databases like PostgreSQL use the Write-Ahead Log (WAL) — the invisible hero behind safe commits and crash recovery — to guarantee atomicity, ensuring that a transaction either completes fully or not at all.

✅ TL;DR Cheatsheet

Property	What it Means	Example Scenario
Atomicity	All-or-nothing transactions	Debit and credit in money transfer
Consistency	Rules must be upheld	Check constraints, foreign key enforcement
Isolation	Concurrent transactions don't clash	Read same row, don't see other's changes
Durability	Committed = permanent	Crash-safe after `COMMIT`

Thanks for reading! If you enjoyed this, stay tuned for the next post in the series — and feel free to share your own “aha” moments around ACID in the comments!