Now, to answer your question on back-pressure. Let me draw an analogy from an experience I actually had during our covid 19 vaccination.

So my wife and I went to get vaccinated at a centre. We parked the car and saw a queue being formed right outside, of people waiting to get vaccinated. That queue reached from the parking place up to this tent-like structure.

Some volunteers came, and asked for proof of location, health card information etc and input those information into their iPads. And while that was happening, another volunteer at the front of our queue (and as we will find out soon, at the back of another) asked for 10 people to get in. When our turn came, we went inside and faced a similar, “controlled” and on-demand queueing system, we get called in groups, we enter in groups, and get serviced, and exit the premise. While this felt like a lot of rules to be implemented, it did end up feeling “effective”. The doctors who were giving vaccines did not have a crowded hall, and that hall had low number of people, manageable and quickly emptiable. On the other hand, you never really waited too long at any of those buffers.

Now, think about the nature of this group act, from the “provider’s” (i.e. volunteers’ or doctors’) perspective, they are obviously fewer in numbers than us, and they can only take so many at a time, by giving them the calling capability, the capacity is being managed. The traffic (i.e. we who are waiting to get vaccinated) are parked and get serviced only when the persons responsible to process are capable of doing so, and it is not something we see (i.e. when the person before me finishes I can “just go”) but that process is hidden from us. and we get called in batches, and that batch number often has a connection with the provider numbers (if there are 4 doctors maybe a batch of 2*4 or 3*4?).

This description is based on my experience and may not have any resemblance at all with the actual process or statistics behind it but let’s convert this whole “pipeline” into a programming one. You have a steady stream of data, and there are dedicated functions (let’s stick to functions now, simpler ones, and let’s not get to multithreading), that transform them, and output of one function is the input of others, until you get the satisfactory computation.

If these functions have limited processing power, and data just keeps coming in, why not have the data parked, and only process a handful at a time? So, welcome the data, but take only what your capable of. This phenomenon, this artificial buffer of data waiting to be processed- is back-pressure. If you think of it as a FIFO (First In First Out) queue, and the entrance is considered as “back”, then the pressure built up from incoming requests, would be back-pressure.

I am not so good with ELI5s and this was an attempt. Apologies if I failed at it.

Hello and welcome to DevTalk. I am not a moderator here but as someone who’s been active since this forum began, asking questions or opening posts is not considered a mess here but are welcome. And this is a place I interacted with some of the friendliest programmers I have met. So you are welcome to ask questions. Although ElixirForum is equally friendly.

This is a great idea @jaeyson!

We were going to start a ‘Glossary’ section on the Elixir Forum where a thread would be posted about something, and then people could explain it in their own words. If you’re a member you can see the thread here: https://elixirforum.com/t/do-you-think-we-need-a-glossary-section/12988

I think we could do such a version here (general dev), then another on the new Erlang Forums for BEAM related stuff - what does everyone think?

Great post btw Mafinar!