コンポーネントのキューについて

(コンポーネントのキューはGo言語のチャネルで作られていますが、以下の説明は(Go言語を知らない方のために)理解のしやすさを優先し若干正しくないですが、理解のしかたとしては正しいように書いてあるつもりです)
コンポーネントは独立したコンテキスト、スレッドで並列に動作すると書いた直後で申し訳ないですが、じつはコンポーネントはそこまで並列に動作するわけではありません。各々のコンポーネントのキューはサイズが1だからです。
キューにはサイズ以上のPayloadを含むコンポーネント変数をいれることはできないため、1度キューにPayloadを含むコンポーネント変数入れたら、次のコンポーネントが動作を開始しキューから取得したあとでないと、次のPayloadを含むコンポーネント変数を入れられません。入れられない間はそのスレッドはキューが空くまでブロックされ動作を停止します。
同様に、次のコンポーネントは自身のキューにPayloadを含むコンポーネント変数が入れられるまでスレッドはブロックされ動作を停止します。ブロックしているスレッドはキューにPayloadが入れられたら、それを取得し動作を開始します。
コンポーネントはHTTPRequestのようにネットワーク処理をともなう比較的動作が重たいものと、CSVReadのようにディスク読み込みのI/O処理がありますが比較的動作の軽いもの、TemplateのようにI/O処理もなくテンプレートのサイズや内容によりますが動作の軽いコンポーネントがありますが、上記のように先のコンポーネントの動作に詰まるように前のコンポーネントは動作を停止することが多いと思います。
仮にチュートリアルの例でCSVが1万行あったとして、キューのサイズも1万あれば、次のコンポーネントの動作完了具合に左右されず前のコンポーネントはキューにためることによって動作を完了することは可能ですが、最終的にはMailSendコンポーネントのキューに1万たまった状態になりアクション全体としてみれば速度というめんで効率はよくはありません(たぶん効率のいいシチュエーションもあるとは思うが思いつかない)。
キューは1万に大きくしたところでメモリをそこまで使うものではありませんが、入れられるPayloadによっては非常にメモリを使うことになるので、キューのサイズが1というのはメモリと速度というめんでバランスがいいサイズだと思います。

PostMappings時はコンポーネントは入力として使ったcvと、これから次のコンポーネントのキューに入れるcvの2つが同時に存在することになるのですが、PostMappingsの式の中ではcvは入力のほうのcvを指し、cvnは次のコンポーネントに渡すcvを指しています。
入力で使用したPayloadは cv.Payload で参照でき、これから次のコンポーネントに渡すものは cvn.Payload で参照できます。