Lago每天扛住百萬級調用，3年后承認：當初選Ruby賭對了

2022年，Lago團隊在技術選型上做了一個"過時"的決定——用Ruby on Rails搭建核心API。當時隔壁工位的創(chuàng)業(yè)團隊正在狂熱追捧Rust和Go，他們的技術棧PPT里連Python都顯得老氣。

三年后，這個賬單基礎設施公司每天處理數(shù)百萬次API調用，累計完成多輪Ruby/Rails版本升級。創(chuàng)始人Raffi在博客里扔出一句話：「要是今天重新創(chuàng)業(yè)，我們還是會選Rails。」

這不是懷舊，是算賬后的結論。

被誤解的"中年技術棧"

Ruby的公眾形象正在經(jīng)歷奇怪的錯位。一方面，它是TIOBE排行榜上穩(wěn)步下滑的老牌語言；另一方面，支撐它的公司名單讀起來像硅谷的"成年人俱樂部"——Shopify、GitHub、GitLab、Basecamp。

這些公司的CEO不再是二十多歲的YC畢業(yè)生，而是"中年爸爸"（Raffi的原話）。你可以把這解讀為Rails過氣的證據(jù)，但Lago團隊給出了另一個視角：能陪企業(yè)從初創(chuàng)走到成熟，本身就是技術棧的稀缺能力。

GitHub 2008年上線，Shopify 2006年，Basecamp更是2004年的古董。它們沒有在某個增長節(jié)點被迫重寫核心系統(tǒng)，這種 longevity（長期生命力）在創(chuàng)業(yè)圈被嚴重低估。

Lago的賭注建立在同一個邏輯上。他們啟動時沒選"最性感"的技術，而是選了團隊有十年經(jīng)驗的工具。「別因為你的YC同學用什么，或者當下最潮的創(chuàng)業(yè)公司用什么，就選擇那個技術棧。」Raffi寫道，「選能讓你交付最好產品的。」

API-only模式的隱藏收益

Lago的具體用法值得拆解。他們沒有用Rails的完整版，而是啟用了API-only模式——砍掉中間件棧、跳過視圖渲染，保留遷移（migrations）、驗證（validations）、Active Record、后臺任務這些核心模塊。

結果是什么？更少的時間花在"膠水代碼"上，更多的時間花在產品功能上。

這個選擇在創(chuàng)業(yè)早期產生了復利效應。當競爭對手還在調試微服務之間的通信協(xié)議時，Lago已經(jīng)上線了計費核心功能。Rails的約定優(yōu)于配置（convention over configuration）在這里不是口號，是實打實的速度優(yōu)勢。

但Raffi對"速度"的定義很精確：不是寫代碼快，是產品迭代快。Velocity matters most——這是他反復強調的，在構建產品公司的階段，幾乎沒有什么比這更重要。

擴展性爭議的真相

Rails最常被攻擊的點是擴展性。在"幾個月內ARR沖到數(shù)千萬美元"成為創(chuàng)業(yè)敘事標配的時代，這個批評聽起來尤其致命。

Lago的回應很直接：擴展性是架構和運維問題，不是框架限制。

他們現(xiàn)在的規(guī)模——每天數(shù)百萬事件和API請求——遠未觸及Rails的天花板。Shopify、GitHub、GitLab的體量更是證明了這個框架的上限比輿論想象的高得多。

Raffi承認團隊在某些場景引入了Go和Rust，但定位非常清晰：不是替換Rails，是 offload（分流）特定任務。他們不讓Rails做所有事，接受它在某些領域的平庸，以此換取核心路徑的高效。

這種"混合架構"比全面微服務化更克制。沒有痛苦的rewrite（重寫），沒有為了技術政治而技術政治。

人才焦慮與現(xiàn)實

最后一個擔憂是關于人的：年輕畢業(yè)生離開學校時，對Rails的興奮度確實不高。Lago怎么解決這個問題？

他們的答案是選擇性招聘。不是招幾百個工程師然后篩選，而是極度挑剔地小規(guī)模擴充。Ruby工程師的存量仍然可觀，其中能駕馭生產環(huán)境規(guī)模的更是稀缺資源——但Lago只需要找到對的人，而不是填滿工位。

這個策略能跑通，部分得益于他們的業(yè)務特性。賬單基礎設施不需要追逐最新的AI框架熱度，需要的是穩(wěn)定、可預測、能長期維護的系統(tǒng)。

Raffi在文章結尾留下一個開放的問題：當技術選型的話語權被"趨勢"和"社交壓力"主導時，有多少創(chuàng)業(yè)團隊在為自己并不真正需要的東西支付溢價？