elvanja
I have a rather expensive action (some PDF generation and upload to an other service) that occurs when related API endpoint is invoked. At the moment, there’s a pool of workers processing those requests and doing what they’re supposed to. However, this approach results in workers filling up their inboxes, potentially overwhelming the system.
The idea is to apply back pressure to API clients and just reject requests if certain conditions are met, e.g. all workers are busy.
Now, workers would be consumers within GenStage driven architecture. However, I’m at loss as to how to construct the producer part. Or, I could make it so that requests are queued somewhere and a producer that reads them, but no idea how to apply back pressure to API clients.
GitHub - loucash/eqm: Erlang pub sub with supply-demand channels · GitHub solves this idea in the sense that I can use it in e.g. endpoint controller to dispatch work to workers and get information if the pool is exhausted or not, consequently informing the API client. So I’m looking for a similar solution via GenStage, if applicable.
Thank you for your time!
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
technomage
Look at the buffering demand part of the GenStage docs GenStage — gen_stage v1.3.2. It includes a QueueBroadcaster which shows how to manage demand and back pressure. In the case of a web API the caller can make calls any time they choose. You would need to provide some reply they interpret as rejecting input that they would be responsible for resubmitting at a later time. This would be similar to how the public APIs like google provide rate limits. The request gets an error that is interpreted as hitting a limit.
jeroenvisser101
There’s also an example in the gen_stage repo for rate limiting that you might want to check out.
elvanja
I gave it a look before, it does show how to rate limit from consumer perspective, but didn’t help with the problem of informing the clients of that rate limit. Clients in this case come even before producer. Maybe I missed something, will give it another look. Thanks!
elvanja
Excellent, seems to be on the right track.
Thank you very much!