Iteratees allow us to consume data streams and enumerators to produce data streams. With their reactive programming model, we just say what to do when data is available. But how is the data flow controlled? Consider, for instance, a situation where a producer generates data at a higher rate than what the facing iteratee can consume, what happens then?

In that case, iteratees impose their speed to data producers. It means that if your server is slower than a client uploading a file, the uploading process will be slowed down according to the iteratee processing speed. This feature is called back-pressure handling.

Conversely, in some cases, you don't want things to be slowed down, for instance, if you are serving data to a client that has a low download rate and this data is directly streamed from a database and holds a database connection. In this case, this client is causing contention on your database, so it is better to fetch as much data as possible from the database to your server's memory. This buffering logic can be achieved by an enumeratee, and Play already provides a ready-to-use implementation via the Concurrent.buffer method.

A slight variant of this situation is when the nature of the streamed data allows the client to eventually miss some pieces (for example, when streaming audio or video data). In this case, instead of buffering data in your server, you can just drop some elements. Again, this job can be achieved by an enumeratee, and, again, Play provides a ready-to-use implementation via the Concurrent.dropInputIfNotReady method.