On July 3, 2026, around 3:52 PM UTC, something unusual happened.
My production database, Cloudflare D1, started returning intermittent errors. I hadn’t deployed any new code. Nothing had changed on my end. The database itself was having a rough afternoon.
Cloudflare classifies these as transient errors and recommends retrying requests. That’s perfectly reasonable.
What caught my attention wasn’t the outage itself. It was how different parts of Datespots reacted to it.
The homepage at datespots.city started returning 503 Service Unavailable.
Meanwhile, city sites like nyc.datespots.city continued serving pages normally.
Same application. Same infrastructure. Very different outcome.
That told me something important.
The city pages had quietly become much more resilient over time. They already relied on cached data stored across Cloudflare’s edge network, so they weren’t dependent on the database for every request.
The homepage wasn’t.
It still expected the database to be available every single time someone visited.
The weak link
Every architecture has one.
Mine wasn’t the database itself. It was the assumption that the database would always respond.
The homepage only needed a small amount of information: which cities are published and when they were last updated. Even so, it fetched that information directly from D1 every time.
When D1 struggled, the homepage struggled.
Looking back, it was an easy dependency to overlook because it had never caused a problem before.
The fix
I didn’t replace D1.
I simply stopped treating it as the only place that knew the answer.
The homepage now follows a much more forgiving process.
First, it asks D1.
If D1 is temporarily unavailable, it retries a few times because transient failures do happen.
If that still doesn’t work, it falls back to data that was already mirrored to Cloudflare KV the last time a city was published.
And if even that isn’t available, it serves a recently cached version instead of showing an error immediately.
In other words, the application now has multiple opportunities to recover before giving up.
Most visitors will never know the database had a bad day.
It’s not about hiding failures
Some parts of Datespots genuinely require the database.
Publishing new cities, editing content, and running background workflows all depend on D1. If the database is unavailable, those operations should fail.
That’s expected.
Reading content is different.
If someone is opening a guide to Paris or looking for date ideas in Tokyo, serving information that’s a few hours old is almost always better than serving nothing at all.
For read-heavy applications, availability often matters more than absolute freshness.
What I learned
This incident wasn’t caused by a bug in my code.
It exposed an architectural assumption that had quietly existed since the project started.
The city pages had evolved into a resilient, cache-first system.
The homepage hadn’t caught up.
Sometimes outages don’t reveal what’s broken.
They reveal what’s inconsistent.
A few hours of work turned one database dependency into several layers of fallback, making the homepage behave much more like the rest of the platform.
Hopefully the next time D1 has a bad afternoon, visitors won’t notice.
And that’s exactly how infrastructure should work.