A visual, interactive explainer of how Elixir's GenStage library implements demand-driven backpressure between producers and consumers. It walks through the core problem of unbounded queues, introduces the concept of demand as a bounded counter, and explains max_demand and min_demand settings with animated playgrounds. It also covers how multiple consumers subscribe independently to a producer, how the DemandDispatcher routes events based on demand, and mentions Broadway as a higher-level abstraction built on GenStage.
Table of contents
The ProblemDemandParallelization StationGenStage, FinallyDemand and Concurrency Are Different KnobsPut the Whole Loop TogetherConclusionQuestions this post answers
What do max_demand and min_demand mean in Elixir GenStage?
Max_demand sets the maximum number of events allowed in flow for a subscription and also the size of the first request a consumer sends. Min_demand is the remaining-demand threshold that triggers another request; for example, with max_demand 6 and min_demand 2, once only 2 units of demand remain, the consumer asks for 4 more events, letting the producer fetch while the consumer keeps working. daily.dev surfaces deep dives like this for developers tuning concurrent pipeline throughput.
How does GenStage prevent a fast producer from overwhelming a slow consumer in Elixir?
GenStage requires the producer to send only as many events as the consumer has explicitly requested through a numeric demand count, rather than pushing events at its own pace. The consumer says 'you may send n more events,' not 'send n events per second,' so an idle or slow consumer simply stops receiving new events until it asks again, keeping the in-flight queue bounded. developers designing bounded queues can track this kind of backpressure pattern on daily.dev.
How does GenStage route events when multiple consumers subscribe to one producer with different processing speeds?
The default DemandDispatcher sends events to the subscription with the most outstanding demand, so faster consumers that finish work sooner and hit their min_demand threshold ask again more often and receive proportionally more events. Slower consumers naturally receive less work because they request less frequently, without the producer ever measuring their actual speed. engineers comparing dispatcher and load-distribution strategies can follow this topic on daily.dev.