Recent submissions

Comment · 2 months ago
Comment · 2 months ago
That is fair. However, the fact that we have this discussion because I wrote the post in English, I wouldn’t reach out to my fellow engineers to discuss the matter this broadly.
Comment · 2 months ago
Maybe I should have added this part. As a non-native English speaker, using AI to write RFCs, ADRs, and internal documentation, my own writing style shifted so much to the direction that my writing seems like AI.
Comment · 1 year ago
If requests are already hitting your servers, it’s too late — you’re burning CPU and bandwidth before rejecting. I built Rately to solve this at the edge: set limits by user, IP, or plan (e.g. free = 1k/day, pro = 1M/month) and return 429s before traffic reaches your infra. Keeps apps simple and protects backend capacity.
Comment · 1 year ago
Interesting, but still your Rail app needs to apply the rate limit logic working with Redis, maybe your DB will be protected, but you will still receive the traffic through your network, meaning more ingress cost, along with CPU to process all the incoming requests.
Comment · 1 year ago
It's already too late if requests are hitting your service. What happens when a customer sends x100 traffic all of a sudden, your Rails backend needs to scale or crash to handle the rate limiting.
Comment · 1 year ago
Correct, pricing would be based on the traffic volume.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton