About me:
Former Amazon Prime Air and Twitch engineer focused on distributed systems, reliability, and large-scale data pipelines.
Recently building EZThrottle — a system designed to coordinate API traffic, retries, and fairness across multi-tenant and agent-driven workloads. Think: preventing retry storms, smoothing partial outages, and making backend systems more predictable under chaotic load.
I care a lot about:
- Reliability under real-world failure conditions (partial outages > total outages)
- Multi-tenant fairness and traffic shaping
- Systems that reduce operational burden, not add to it
Looking for roles or contracts where I can work on:
- Infrastructure / backend systems
- Distributed systems / reliability engineering
- High-scale APIs or data pipelines
I’m curious if you are looking into gleam at all. I have written elixir/gleam interop otp library. Probably will help a lot for safety in finance. I could help turn certain components into for type safe gleam code
An api rate limit router - it’s gives a queue per user to solve noisy neighbors, it allows
the user user to reroute 500s to other regions automatically, the api provider can tune the speed of request with headers. It should be a massive speed boost because non-beam servers waste performance on sleeping threads. It’s works by my edge servers doing all the retrying across different regions and it can send webhook to you across regions which means we delivery if you an all your downstream are up in one region. It’s actually already ready but of course no one wants to trust me with their traffic. Nobody wants to even read the design doc nor sdk. I’m hoping that upcoming new agents bring so much traffic that people look for this category of software. Until then I guess I am Cloudfare before the world got hit by bot scrapers.
The modern orchestrator are reactive, they don’t handle spikey traffic. Your favorite retry library will cause retry storms for downstream dependencies and your public APIs. Remember EZThrottle blog posts
Ezthrottle works by sending the request and depending on what error code the user wishes to reroute on, it will send to another region. It give the user a chance to say something different in case the api misclassifies the error. The user would have to tune it.
Thanks for this. I was in the camp of trust the LLM but y’all have made valid points. After discussing with ChatGPT, it agree there are some areas where it should not be trusted as accurate, but it said with historical facts like the holocaust it should be high. Idk, perhaps we need labs to produce a chart of it level of trust deserve to certain topics
Im curious if you guys are seeing rate limiting issues. Agents sharing api keys tend to be retry storm monsters. I wonder how agent companies will address
Fair pushback — to clarify, I’m not assuming incompetence or suggesting infra should paper over bad architecture.
By “losing sleep” I really mean on-call fatigue during partial outages — the class of incidents where backoff, shedding, and breakers exist, but retry amplification, shared rate limits, or degraded dependencies still cause noisy pages and prolonged recovery.
I’m trying to understand how teams coordinate retries and backpressure across many independent clients/services when refactors aren’t immediately available, not replace good architecture or take ownership of someone else’s system.
If you’ve seen patterns that consistently avoid that on-call pain at scale, I’d genuinely love to learn from them.
Agree backoff+jitter is table stakes, and load shedding/backpressure is necessary under sustained overload. The tricky cases I’m digging into are shared rate limits (429s) and many concurrent clients/agents where local backoff isn’t coordinated and you still get herds after partial outages. Curious what patterns you’ve seen work well for coordinating retries/fairness across tenants or API keys?
I hear a lot of people complain that Gleam is “not OTP.” They’re right. At the time of writing, Gleam still doesn’t have a registry or pubsub. If you ask the Gleam team, they’ll tell you to use external calls — which works, but is a pain to reproduce consistently across projects.
So I wrote Glixir, a library that wraps common OTP patterns in Gleam using Elixir’s battle-tested OTP library. It’s not as type-safe as Gleam, but I needed something production-ready today, not next year.
This lets you:
Use supervisors, GenServers, and pubsub patterns from Gleam.
Stay in Gleam where it makes sense, but drop down to Elixir OTP when you need reliability.
Ship code faster without reinventing OTP on the Gleam side.
Obviously there are trade-offs — you give up some type safety, and it’s not “pure Gleam.” But if you’re trying to build something real, you may find this a useful middle ground.
It's MIT so if you disagree with direction you can fork and do whatever you want.