Back-pressure en Flow: secuencial por defecto, y qué compra buffer()

La propiedad más importante de un `Flow` es la menos publicitada: es **secuencial**. `emit(x)` es una llamada suspendible que no retorna hasta que el lambda del colector terminó de procesar `x`. Productor y consumidor se alternan entonces — producir, consumir, producir, consumir — y el tiempo total para `n` elementos es `n * (producir + consumir)`. No hay ningún thread pool haciendo algo astuto por debajo, ni ninguna cola oculta. Por eso un Flow no necesita sincronización y por eso su manejo de excepciones es simple; y también por eso un pipeline ingenuo puede tardar el doble de lo necesario.

`buffer()` es el operador que rompe la alternancia. Inserta un canal entre las dos etapas, así el productor corre adelante hacia el buffer mientras el colector trabaja, y el total pasa a estar acotado por la etapa *más lenta* en vez de por su suma. Con cuatro items, 30 ms de producción y 70 ms de consumo, secuencial cuesta 400 ms y con buffer cuesta 310 — `producir + n * consumir`. Se conservan todos los valores; lo que pagás es memoria, y `buffer(n)` te deja decir cuánta. Es el operador de mayor apalancamiento en Flow, y es una palabra.

`conflate()` es `buffer(CONFLATED)`: un buffer de un lugar donde un valor nuevo pisa a uno viejo. El productor nunca espera, la memoria queda acotada en un elemento, y el precio es que los valores para los que el colector estaba ocupado se **saltean por completo** — nunca se empiezan. Para una UI que renderiza el último estado, un dashboard, un ticker de precios, eso es exactamente lo correcto: un valor que ya fue superado no vale el trabajo. Para cualquier cosa que no podés perder, es pérdida de datos con nombre amable.

`collectLatest { }` se ve parecido y es fundamentalmente distinto: en vez de saltear valores que no empezaste, **cancela el trabajo en curso** cuando llega un valor más nuevo. Solo el último valor llega al final del bloque. Ese es el operador del trabajo obsoleto — búsqueda mientras escribís, una pantalla que se re-renderiza desde el estado más nuevo, cualquier request cuyo resultado no vale nada en cuanto existe una entrada más nueva. Como la cancelación es cooperativa, el cuerpo tiene que suspender de verdad para que funcione: un cuerpo que hace un cómputo bloqueante largo nunca se cancela, y `collectLatest` degrada en silencio a un `collect` plano.

`flowOn(dispatcher)` cambia dónde corre lo que está **aguas arriba**. Todo lo que está encima en la cadena se ejecuta en ese dispatcher; todo lo de abajo se queda donde está el colector. Es la única forma correcta de mover el trabajo del productor fuera del hilo actual, porque emitir directamente desde otro contexto es ilegal (esa es la regla de preservación de contexto del contrato de Flow). Dos cosas sorprenden: aplica solo hacia arriba — la posición en la cadena importa — e introduce un buffer propio, así que mover una etapa a otro dispatcher puede cambiarte los tiempos aunque nunca hayas escrito `buffer()`.

La concurrencia dentro de un Flow es opcional y explícita. `map { }` es secuencial por construcción. Cuando cada elemento necesita una llamada asíncrona independiente, `flatMapMerge(concurrency = k) { flow { … } }` corre hasta `k` flows internos a la vez e intercala sus resultados; `flatMapConcat` mantiene el orden de la fuente a costa del paralelismo; `flatMapLatest` cancela el flow interno anterior cada vez que llega un elemento nuevo. Esas tres son las mismas tres respuestas que dan `flatMap`, `concatMap` y `switchMap` en Reactor, y elegir entre ellas es elegir entre throughput, orden y obsolescencia.

La fusión de operadores es por qué esto sigue siendo barato. Los operadores adyacentes `flowOn`, `buffer` y `conflate` los colapsa el runtime en un único canal con una única configuración, así que escribir `.flowOn(IO).buffer()` no crea dos colas. También significa que la posición de `buffer()` es significativa de un modo en que la de `map` no lo es: un buffer insertado antes de una etapa cara desacopla esa etapa de lo que tiene arriba, y buffers en ambos extremos de una etapa lenta del medio dejan correr las tres a la vez.

Una checklist práctica. Medí antes de agregar un buffer — bajo `runTest`, `currentTime` te da tiempos virtuales exactos, así que «¿el colector es el cuello de botella?» es una pregunta con un número y no una opinión. Agregá `buffer()` cuando ambas etapas son genuinamente lentas y tenés que conservar todos los valores. Usá `conflate()` cuando solo importa el último valor y el trabajo por valor es corto. Usá `collectLatest` cuando el trabajo en vuelo pierde valor ante una entrada más nueva. Y dejalo secuencial cuando ya es lo bastante rápido, porque secuencial es la versión sin cola, sin crecimiento de memoria y sin sorpresas.