Forem: Paul

How I stopped my API from going down on a €5 VPS

Paul — Mon, 27 Apr 2026 12:38:31 +0000

My server went down three times in one day. The first time I didn't even notice.

That last part is the real problem. No alerts, no health checks, no monitoring. I only found out because I happened to check the dashboard. By then it had already happened twice more.

First lesson: build a health check that lives somewhere else

If your health check runs on the same server that crashes, it crashes with it. Obvious in hindsight. I set up an external uptime monitor that pings a /health endpoint every minute and sends a notification when it does not respond. Free tier on most uptime tools covers this. Do it before anything else.

What was actually causing the crashes

After looking at the logs, the cause was simple. A single customer was sending 3,000 requests per second. No malicious intent, they were just running a batch job and did not know there were limits. The API docs said "unlimited" and they took that literally.

I had tried to add rate limiting earlier using the built-in API key management from my auth library. It never worked reliably. The bigger issue was that subscription state got cached, so when a user upgraded their plan the old limits stayed active for a while. It created subtle bugs that were hard to track down, so I eventually ripped it out.

This time I wanted to build something I actually understood.

The solution: two-layer rate limiting with Redis

After some research I landed on a two-layer approach: a daily quota and a per-minute burst limit, both backed by Redis atomic counters.

The logic runs like this. Every request first checks the daily quota. If that passes, it checks the burst limit. If either fails, the request is blocked and returns a 429.

Tier definitions live in one file:

export const RATE_LIMITS = {
  anonymous: { limit: 30,  windowSeconds: 86400 },
  free:      { limit: 100, windowSeconds: 86400 },
  trial:     { limit: 500, windowSeconds: 86400 },
  pro:       { limit: 5000, windowSeconds: 86400 },
};

export const BURST_LIMITS = {
  anonymous: { limit: 5,   windowSeconds: 60 },
  free:      { limit: 10,  windowSeconds: 60 },
  trial:     { limit: 30,  windowSeconds: 60 },
  pro:       { limit: 120, windowSeconds: 60 },
};

The daily check uses a Redis key scoped to the current calendar date:

const dailyKey = `ratelimit:daily:${identityKey}:${dateKey}`;
const dailyCurrent = await redis.incr(dailyKey);
if (dailyCurrent === 1) {
  await redis.expire(dailyKey, 48 * 60 * 60);
}
if (dailyCurrent > limit) {
  return { allowed: false, remaining: 0 };
}

Only requests that pass the daily check hit the burst counter. The burst key is scoped to a fixed 60-second window:

const burstKey = `ratelimit:burst:${identityKey}:${windowStart}`;
const current = await redis.incr(burstKey);
if (current === 1) {
  await redis.expire(burstKey, windowSeconds + 10);
}

One detail worth keeping: if the burst check fails, the daily counter gets decremented back. A blocked request should not eat into the user's daily budget.

if (!burst.allowed) {
  await redis.decr(dailyKey);
  return { allowed: false, burstLimited: true };
}

Every response also sends back standard rate limit headers so clients can self-throttle instead of just hitting 429 and retrying blind:

"X-RateLimit-Limit": String(result.limit),
"X-RateLimit-Remaining": String(result.remaining),
"X-RateLimit-Reset": String(result.resetAt),

Why this design

Fixed windows are simpler than sliding windows and good enough for this use case. Atomic INCR means no race conditions and no Lua scripts. Daily quota runs before burst so a request that is already over the daily limit does not waste a burst slot.

The tier is resolved from the user's subscription status, which is cached in Redis with a short TTL. This avoids a database call on every request and also fixes the plan-upgrade bug I had before, because the cache expires fast enough to reflect changes quickly.

Testing was harder than building

Getting the implementation right took one failed attempt. The first version had an off-by-one in the window calculation that only showed up under concurrent load. I wrote a small test script that fires requests in parallel across different tiers and checks that the right ones get blocked. Only after that ran cleanly did I trust the implementation in production.

If you are building something similar: write the test script before you deploy, not after.

Adding Cloudflare in front of everything

Rate limiting at the application layer is good but it still means traffic hits your server first. On a €5 VPS with limited bandwidth, even blocked requests have a cost if they arrive at thousands per second.

I added Cloudflare as a proxy in front of the server and set a request rate rule that drops anything above 50 requests per second per IP before it reaches the VPS. Cloudflare absorbs the traffic spike. The application rate limiting handles the finer-grained per-tier logic.

Since then: zero downtime.

What I would do differently from day one

External health check with notifications before anything else
Redis on the same VPS, rate limiting from the start
Cloudflare proxy from the first public launch
Write test scripts for the rate limiter, not just unit tests

The crashes were not a scaling problem. The VPS can handle the load fine with proper caching and controlled concurrency. The problem was that nothing was protecting it.

How I turned a boring government database into a developer API (and got my first paying customer)

Paul — Tue, 21 Apr 2026 03:33:54 +0000

I built a REST API for the Austrian company register - here's what happened

Austria has a public company register called the Firmenbuch. It lists around 500,000 registered companies: addresses, managing directors, shareholders, legal form, and annual financial statements going back years. Useful stuff if you want to research a company before a job application, check a business partner, or just satisfy your curiosity.

The problem: the official way to access this data is painful. You pay €3–7 per company lookup. The UI looks like it was built in 2003. And there is no API, just a SOAP-based web service that nobody would choose to use voluntarily.

I needed to look up company data for a personal project and got frustrated enough to build a wrapper. That was the start of firmafind.

The technical nightmare nobody warns you about

SOAP in 2026 is already bad enough. But the Austrian Firmenbuch takes it further.

Annual financial statements are stored in XML where every field is mapped to a cryptographic code. There is an official "decode key", it is an Excel spreadsheet. A very old Excel spreadsheet. AI tools are basically useless here because the encoding is too obscure and too specific to get right without manually cross-referencing the sheet for every single field.

Getting the parsing right took way longer than building the actual API endpoints. If you ever need to work with Austrian Firmenbuch XML data, expect to spend a good amount of time just figuring out what field HS2 means (it is the equity, by the way).

From web search to API wrapper

The free search tool was getting used but it was a dead end for monetization. I didn't want to put it behind a paywall the whole point was that this data should be accessible to everyone.

So I thought about who else might need this. Developers building CRMs, compliance tools, onboarding flows anyone who needs to look up Austrian company data programmatically and doesn't want to deal with a SOAP API from 2003. I already had all the parsing logic from the search tool, so I rewrote it into clean REST endpoints and added caching to make it actually fast. The government API is slow. With caching, response times dropped significantly.

I made the endpoints available for free at first to see if anyone would use them. They did.

The overengineered detour

Then the API started getting hammered with requests and Vercel's free tier couldn't keep up. I needed to monetize. My first idea was a credit system users start with 500 credits, each request costs some, buy more when you run out. Seemed logical.

It was a mistake. Transaction handling, credit balances, edge cases everywhere. I spent weeks on infrastructure that had nothing to do with the actual product. Eventually I scrapped the whole thing and switched to simple monthly subscriptions. Should have done that from day one.

First paying customer and a pivot

I did almost no marketing. A few posts on niche Austrian subreddits that barely got seen. No ads, no outreach campaigns.

Then last week I got my first paying subscriber. What surprised me: they are not Austrian. They are an international company that needed to look up Austrian business partners. The product was in German. They subscribed anyway.

That was enough signal for me. I translated everything to English and shifted focus toward international customers, compliance teams, legal firms, fintechs operating in Austria who need programmatic access to Austrian company data. The data is local but the problem is not.

What's next

The roadmap right now:

More European countries (same API structure, different registers)
Credit scoring based on annual financial statements
KYC API with modular Austrian register coverage: insolvency registry, beneficial ownership register, entity mapping

The free search tool stays free. The API is at firmafind.at if you ever need Austrian company data in your stack.

Lessons learned: don't overbuild your billing system, post in the right communities, and pay attention when a customer finds you instead of the other way around - they are telling you something.