DEV Community: Derrick

How to Build a "Financial Firewall": Multi-Cloud High Availability on a $0 Budget

Derrick — Mon, 09 Feb 2026 14:15:00 +0000

The "Cloud Success Tax" is a silent killer for indie hackers and startups. You build a project, it gets a bit of traction, and suddenly you're hit with overage fees and egress costs that turn your hobby into a liability.

Most developers are taught that High Availability (HA) is an expensive enterprise luxury involving complex clusters and load balancers. I wanted to challenge that by building a "Financial Orchestrator" directly into the gateway layer.

The Theory: Financial Waterfall Routing

Instead of just balancing load, why not orchestrate it based on priority and cost?

The idea behind Waterfall Routing is simple: maximize your free-tier credits across multiple providers before you spend a single cent.

1. The "Monthly Cap" Pivot

Most cloud providers have generous free tiers (e.g., 1M requests per month). In Crate.cc, I've implemented a way to set a "Usage Threshold." Once you hit 90% of your free tier on Provider A, the gateway automatically "switches tracks" to Provider B.

You aren't just scaling for performance; you're scaling for arbitrage.

2. The Automatic Error Fallback (The Safety Net)

Usage caps protect your wallet; In-Flight Retries protect your uptime. Free-tier instances are often "burstable" or shared, meaning they can be flaky.

Crate.cc acts as a defensive guardian:

Detection: If a destination returns a 5xx or hits a network timeout.
Redirection: It immediately retries the request against your secondary "Safety" destination.
Method Safety: Built in Go, the logic ensures we only retry "safe" methods (like GET). We never blindly retry a POST or DELETE to avoid double-processing your data.

Implementation: Why Go and Redis?

To make these decisions in real-time without adding 500ms of latency, the architecture relies on:

Redis Atomic Counters: To track request counts across a global distributed gateway.
High-Performance Go Routines: To handle background health checks and threshold monitoring.
Stateless Logic: Ensuring the "hop" between Cloud A and Cloud B is nearly invisible to the end-user.

The ROI: Cloud Success Tax vs. The Crate Waterfall

Feature	Standard "Single Cloud" Setup	The Crate.cc "Waterfall" Setup
Primary Destination	1M Free Requests (Cloud A)	1M Free Requests (Cloud A)
Overages (Next 2M)	~$2.00 - $7.00 + Egress	$0.00 (Waterfall to Cloud B & C)
Uptime Strategy	Manual or Expensive LB	Automatic In-Flight Retries
Stability	Single Point of Failure	Multi-Cloud Resilience
Monthly Cost	Variable Overage Anxiety	Flat $5/mo (Crate standard plan: 1tb data)

Conclusion: The "Zero-Ops" Multi-Cloud

You don't need a $200k/year SRE team to set up multi-cloud failover. You just need a gateway that understands that Uptime and Budget are the same thing.

I'm building Crate.cc to give developers the tools to scale without the fear of a surprise bill.

I'm currently building Crate in public. If you have thoughts on "idempotency-aware" retries or how you're hacking free tiers, let's talk in the comments!

I accidentally DDoS'd myself (and why you should too)

Derrick — Tue, 03 Feb 2026 18:45:40 +0000

I launched my SaaS, Crate, just 72 hours ago. It’s an API Gateway designed to protect backends from traffic spikes and anomalies.

Last night, I became my own first victim.

I was working late on a new feature and needed to verify a config change. I pulled up my admin dashboard, not realizing it was the production tab and my auth token had expired hours ago.

What happened next was a classic "Frontend vs. Backend" failure that I didn't see coming.

The "Retry Storm"
I assumed my frontend was smart. I assumed that if it hit a 401 Unauthorized error, it would gracefully redirect me to the login page.

I was wrong.

Instead, a race condition in my data-fetching logic caused the dashboard to attempt to "refresh" the view immediately upon failure. Because the token was still invalid, the refresh failed again. And again.

In less than 30 seconds, my laptop rapid-fired requests to my production API, all returning 401.

If this had been a user, they would have just seen a spinning loading wheel. But because I was "Dogfooding" my own tool, I got to see the backend consequence.

The Watchdog Barks
I built Crate using Go and Redis specifically to catch this kind of noise with zero latency. I set up a "General 400" rule to track client-side errors, assuming it would mostly catch bad form submissions or broken links.

I didn't expect it to catch me.

Less than a minute after opening my dashboard, my phone buzzed.

Subject: Alert: High Volume of 4xx Errors Trigger: > 10 errors in 1 minute

The alerting engine had detected the anomaly—a 1200% spike in error rates from a single IP—and fired the notification.

Why this matters... (The Dogfooding Argument)
If I hadn't been using my own tool to build my own tool, two things would have happened:

The Bug would have shipped: I would have deployed that frontend logic to customers. A user with an expired token would have silently hammered my API in the background, wasting their bandwidth and my server resources.

I wouldn't trust the Alerting: Seeing that email hit my inbox instantly gave me more confidence in the system than 100 unit tests ever could. Even more so when I saw the resolution email 2 minutes later letting me know the spike was over.

The Fix
I patched the frontend before breakfast. I added a strict check in the API interceptor to halt all outgoing requests immediately upon receiving a 401 and force a hard redirect to /login.

The graph went flat. The alerts stopped.

The Takeaway
We talk a lot about "Chaos Engineering" and complex testing frameworks. But sometimes, the best test is just being tired, having an expired token, and trying to use your own product on a Monday night.

If you aren't dogfooding your own critical path, you aren't seeing the sharp edges.

I'm building Crate in public. If you want to stop your own "Retry Storms" from running up your serverless bill, check it out at Crate.cc.

How I beat the "Serverless Tax" using Go and Redis

Derrick — Fri, 30 Jan 2026 14:30:00 +0000

The Problem

I love Vercel and Netlify for side projects. The developer experience is unmatched.

But I hate the "Success Tax."

The moment a side project gets traction, the function invocation limits kick in. You go from the "Free Tier" to "Enterprise Pricing" overnight, often for traffic that isn't even monetized yet.

I didn't want to migrate to Kubernetes, but I didn't want to pay $20/mo per project just to handle a few spikes.

The Solution: A "Poor Man's" Load Balancer

I realized that while one free tier has limits, three free tiers have triple the limits.

I built a lightweight API Gateway called Crate using Go and Redis.

The Architecture

The Gateway: A Go binary running on a cheap bare-metal server (Colocrossing).
The State: Redis is used for distributed rate limiting and analytics tracking.
The Routing: It uses httputil.ReverseProxy with in-memory round-robin logic to split requests across multiple backends.

Instead of pointing my domain to Vercel, I point it to Crate. Crate then splits the traffic:

33% -> Vercel Project A
33% -> Vercel Project B
33% -> Netlify Backup

The Result

I effectively multiplied my free tier limits. I can now handle 3x the traffic without paying a cent in overage fees.

I also use it to run Hybrid Architectures. I split traffic 50/50 between a Serverless Function (for scale) and a fixed-cost VPS (for baseline load). This keeps my bill predictable.

Want to try it?

I'm looking for 10 developers to help me stress-test the Go implementation.

I'm charging $5/mo (locked in for life) just to cover the server costs.

If you are tired of watching your usage meters like a hawk, check it out here:
https://crate.cc