My MongoDB cluster was in Bahrain. Then the missiles came.
A missile strike in the Persian Gulf took down my MongoDB cluster in Bahrain. I was on the free tier with no backups. 1648 users lost everything and I learned why disaster recovery isn't optional, even for side projects.

I lost users to a war I wasn't fighting#
I never thought a missile strike in the Persian Gulf would be the thing that killed my side project. But here we are.
This is the story of how Comrade Swap, my first product with real users went from a working app to an empty database overnight, and what I should have done to prevent it. If you run anything in the cloud, even something small, this is for you.
The product#
Comrade Swap was a marketplace I built while still in campus, connecting students to other students running small businesses or hustles to survive. No financial records, no payments, just listings, profiles, and messages. 1648 users. Mostly fellow comrades trying to make it work between lectures.
It was small. It was unglamorous. It was mine, and people actually used it.

How I found out#
It started, as these things often do, with an alert I ignored.
Azure pinged me that one of my APIs was failing to start. I have a lot of portfolio projects sitting in that subscription, so the first ping didn't move me. Neither did the second. By the third, I figured I should at least look.
The logs were vague. Nothing screamed root cause. So I did what I should have done first, opened the live URL.

Comrade Swap was up, but empty. Zero items. Zero services. Sign-in broken. Registration broken. The frontend was rendering a hollow shell of an app.
I jumped to MongoDB Atlas. The first thing I saw was a red banner across the top of the dashboard:
Service disruption in Middle East regions.
I checked which region my cluster was in.
Bahrain.
I genuinely paused for a second and Googled whether Bahrain was in the Middle East. Some part of me hoped it wasn't. It is.

Then it hit me. Iranian strikes had taken down AWS infrastructure across the Gulf weeks earlier . Atlas runs on top of AWS, and me-south-1 was one of the impacted regions. I had deployed there because it was geographically closest and felt fast. I never considered that "closest" and "in an active conflict zone" could be the same sentence.
Why the data was actually gone#
Here's the part I didn't understand until it was too late.
I was running on M0, MongoDB Atlas's free tier. M0 does give you a replica set: a primary and two secondaries. For a long time I assumed that meant my data was safe across nodes, which is technically true but with one catastrophic asterisk.

On the free tier, every replica node lives in the same region. Same data center footprint. Same blast radius. Same outage event takes them all down simultaneously.
A replica set protects you from a single node failing. It does not protect you from the region itself going dark.
And M0 has no backups. No snapshots. No point-in-time restore. No cross-region replication. Those start at M10. I had none of them, and I had no mongodump running anywhere else either. No S3 bucket with archives. Nothing.
When the region went down and stayed degraded, my data went with it.
What I should have done#
In hindsight the fixes are embarrassingly cheap:
A nightly mongodump to S3 in a different region. Five lines of bash, a cron entry, a bucket in eu-west-1 or us-east-1. Pennies per month. Would have saved everything.
Multi-region awareness, even on free tiers. If I'd known M0 replicas were single-region, I would have at least kept manual exports. The information was in the docs. I didn't read them carefully enough.
Treating geopolitical risk as a real architectural input. This sounds dramatic for a student project, but it isn't anymore. Data centers are now military targets. The Bahrain and UAE strikes weren't theoretical ,they were drone hits on commercial AWS facilities. Region selection is no longer purely a latency or pricing question. Where your data physically sits matters.
Building DR habits at any scale. I told myself disaster recovery was something "real" companies worry about. That was the actual mistake. The 1648 users didn't care that this was a side project. To them, it was just an app that lost their stuff. Backups, redundancy, and recovery plans aren't features you bolt on once you're "big enough." They're principles. They belong in version one.
What I'm doing now#
A few things have changed in how I build, and they will stay changed:
Every project I deploy now paid or hobby gets an automated
mongodumpto an S3 bucket in a different geographic region. Not the same region. Not the same continent if I can help it.I no longer treat free tiers as production-safe for anything with real users. If I can't afford an M10, I can afford a 5-line backup script. There is no excuse.
I read the durability section of provider docs before I deploy, not after I lose data.
Region choice now factors in geopolitics, not just latency.
To other devs#
If you're shipping side projects with real users, I'm asking you to do one thing this week: write the backup script. Don't promise yourself you'll do it later. Later is exactly when the missile lands.
Free tier is fine for prototypes. It is not fine for the people who trusted you enough to sign up. The gap between "it works on my laptop" and "it survives a regional outage" is wider than most of us think, and it doesn't close on its own.
I lost Comrade Swap because I treated DR as something I'd get to eventually. There is no eventually. There is only what you set up before the bad day, and what you wish you'd set up after it.
Set it up before.
If you've made it this far, thank you. I'm currently building MeetADev a community for devs who'd rather learn from each other's scars than collect their own. That's where I'll be.
1 comment