私は基本的に>>156案に同意ですが
バックエンドは、基本的にCPUはスカスカになり
(ネットワーク処理もCPUはIDLEでしょうから)
read.cgi処理も出来るだろうと考えています。
.datも含めて、オンメモリのキャッシュを有効に活用すれば
sendfileには劣るかもしれませんが、ネットワーク負荷も
静的コンテンツ転送以下に抑えられるでしょうし。
同居すれば、「.datをどうやって取ってくるか」「.dat転送のコスト」
等は無視できるようになりますから。

ただ、(特に開発中は)CGIDSOは非常に有効ですが
これ自体は、(fork/execはしないものの)毎回ロードとリロケーションを行っていると思います。
この点も考慮すると、スカスカって程ではないかもしれません。

それと、index.htmlの作成もbackend側で出来れば、
(連投規制等考えなければいけない点もあるものの)
フロント(.dat書き込み以外のbbs.cgi処理全般に専念)は
ほぼ完全にラウンドロビンで台数増減が自由になると思います。


とはいえ、実験した数字を見てみるのが一番ですね。
backendのCPUに余力がありそうならread.cgiを後ろに回すことも考える、という事で。