如果有寫過 messaging 之類的 web app，那架構上多半會摻了類似的概念。
不過這種全靠 persist socket 的做法有很多缺點：
你要處理訊息接受次數可能是 0, 1, 和多次。本來 http 的傳統架構是 request-response，只有失敗和成功兩種結果。如果是 message queue 的話，就有可能因為斷線重連而變空炮彈 (server 有回你但你沒收到)，光是要解決這問題就很煩了。然後這問題接下來衍生更難的困境
即然 client (browser) 會掉訊息，那麼 server 的行為就需要變成 "最少送成功一次"。這意味有很多情況是同個 message 會重覆發 (在斷線頻發時)，client side 的程式要能處理這種狀況。想也知道要花多少精力維護這種狀況 (every operation must be idempotent)
這問題在 mobile web 上更是嚴重，persist socket 一天斷個十幾次 (3G/4G 隨便斷線的)。在桌機 browser 沒看到的問題通通跑出來了，寫到最後你會想放棄的。
這篇作者提的架構是適合 Single Page App (SAP)。但在 mobile web 上這架構不是很討好，client side js render 在手機上其實很慢，最後都要回歸 server 來 render，而且也不是所有服務都適合 SAP。
最後用 websocket 的省頻寬，省連線數什麼的，這問題在 http2 下已經解決，所以這優點已經消失。
我最近也有這個需求，想幫 Arch Linux Taiwan 架一個論壇，同樣也是在研究 Discourse 與 Flarum 這兩種，但是 SPAM BOT 的預防恐怕是上 ReCAPTCHA 比較有效，也不用考慮從舊系統轉換資料的問題，主要我想用兩者之一是考慮到 RWD 的問題，但還是沒拿定主意。
Digital Ocean 的 $10 主機規格，先不論每天有幾篇文，如果更多人是潛水、只看不發文，還是會有流量在噴，以及大量的 DB queries（如果前面沒擋 cache 的話），這個可能你要更加考慮。
大部份的開發者都不會到達需要 advanced tuning GC 問題的 scale (不然那些用 ruby 的人不都去死了？)。
等到大到某個地步，GC 調到死都調不好，該公司通常已經到了要自己開發/修改 runtime 的 scale。例如 twitter, FB, alibaba....etc
原推文是在抱怨 zookeeper 有 GC pause 的問題，在這個領域裡，她推得這句話是有點道理，畢竟 zookeeper 是底層的 database，不是一般的 application。但如果無限上綱到所有軟體都不該用 GC 那就大錯特錯了