Transducer pipeline or sequential map for low‑traffic Clojure services: which yields lower allocation overhead?

Goal: reduce per‑request memory allocation and garbage‑collection pressure in a Clojure service that processes fewer than ten requests per second.

Constraints: the service must stay responsive under idle periods, avoid unnecessary thread‑pool wake‑ups, and work with a stable Clojure release (1.11 or later). It is unclear whether a transducer pipeline—benefiting from lazy composition without intermediate sequences—outperforms a straightforward sequential map with doall when the workload is sparse, especially considering that transducer ordering can change performance characteristics and that core.async alternatives introduce bookkeeping overhead.

Which approach yields lower allocation overhead for such low‑traffic workloads, and how does pipeline ordering affect the result? Should a simple sequential map be preferred despite its realization cost, or does the transducer advantage persist when request frequency drops below one per second?