I recently worked on a migration from PostgreSQL to Elasticsearch due to high latency even after trying to optimize it a lot via GIN or GIST in pg_trgm, and I think it could be a useful story for anyone that may want to do it
Most rate limiting discussions focus on algorithms: token bucket, leaky bucket, sliding window.
But in real systems I’ve noticed the algorithm often matters less than where the limiter sits in the request path.
If a limiter is placed too late, the system already carried the work too far and you end up with 503 Service Unavailable instead of controlled 429 responses.
I wrote a short piece about thinking of rate limiters as system boundaries rather than just algorithms, including some examples of failure modes when capacity or placement is wrong.
Article:
https://medium.com/p/fe8ad3eae36c
Curious how others approach this in production systems.