幹壞事是進步最大的原動力
Elon Musk 自己貼了以後，有人把白板圖整理成數位圖後好讀一些：
Twitter Architecture 2022 vs. 2012. What’s changed over the past 10 years?
Thank you, @elonmusk for the transparency.
{1/2} pic.twitter.com/Fvbn7EDoOS
— Alex Xu (@alexxubyte) November 19, 2022
不過心裡可以先有底，這是解釋給大老闆聽的架構圖，底層可能還會有不少東西是沒有在這上面的，尤其是其他重要的子系統，像是圖片與影音怎麼處理之類的。
先把圖拉出來看原圖大小 (可以自己點)，比較清楚一點：
從最前端往後看，可以看到 TLS-API 被標成淘汰中，照圖上寫的剩下 Android 版本在用，後續應該是往 GraphQL 靠；另外內部有使用到 Thrift，但沒有標 gRPC，我猜是這邊的主線上沒有 gRPC 而已，其他系統可能還是會有。
另外是有些東西有標 next-gen system，應該就是正在做而還沒上線的東西。
Slack 針對今年年初的爆炸提出了說明：「Slack’s Incident on 2-22-22」，但真正的重點都在 Hacker News 的討論串上：「Slack’s Incident on 2-22-22 (slack.engineering)」。
大概有三件事情可以講，第一個是掛掉的原因，第二個是剛發出來的時候，一堆人對於標題用的「2-22-22」很感冒，第三個是剛剛 (一個小時前)，Cal Henderson (Slack 的 CTO) 跑到 Hacker News 的討論串上回應...
這次的 downtime 主要是發生在 Group Direct Message (GDM) 的部份：
A significant element of the datastore load appeared to be from a query that listed Group Direct Message (GDM) conversations by user. This operation is fronted by our cache tier, so the high query load seemed to indicate something was wrong with our caches.
這個 GDM 的查訊效率不高，而是靠 cache layer 撐住的，加上二月 22 日那天他們在更新 Consul 的 agent，導致 hit rate 的下降，以及遇到一個比較大的 peak time，接著就壓垮了資料庫。
oh，這中間還有 Vitess 一起進來打架，原文講的比較清楚，但需要花一些時間看。
剛發表出來的時候，其實大多數的討論反而是在討論「2-22-22」這件事情，這的確是很差的表示方法，尤其對於一份公告來說，不過這個問題本來就是個 flame war 等級的話題...
在重刷頁面的時候發現 iamcal 這個帳號的回應，而 Cal Henderson (Slack CTO) 的個人網站是 www.iamcal.com，雖然不確定這是不是本人帳號，但看起來之前在 2011 註冊後都沒動...
這個帳號回了兩個訊息，一個是提到 AWS 上其實很常看到 failure，需要靠本身架構的穩定性來撐：
Our underlying hardware (AWS) is nothing like this reliable. We see regular (several times a year) failure of racks of machines or whole DCs.
Across the whole fleet (all services), we lose 1-10 servers per day as a baseline. Major events are then on top of that and can impact thousand of hosts at once.
另外一個是反駁自以為的量級估算：
> Even the largest Slack instance probably has under 100,000 users and less than 1000 peak messages per second.
This is not true, by an order of magnitude.
好像還可以繼續在盯一下，不知道還會不會有回應...
在 Hacker News Daily 上看到「MonolithFirst」這篇，是 Martin Fowler 在 2015 年寫的文章，對應在 Hacker News 上的討論「Monolith First (2015) (martinfowler.com)」也頗有趣的，可以一起翻。
tl;dr：他的文章就是在講新專案用 monolith，不要去碰 microservice。
文章開頭提到了就他觀察到的情況：第一點是，幾乎所有成功的 microservice 案例都是從 monolith 起頭，再轉到 microservice 環境；第二點是，幾乎所有一開始用 microservice 的案例，在後來都遇到嚴重的問題：
As I hear stories about teams using a microservices architecture, I've noticed a common pattern.
- Almost all the successful microservice stories have started with a monolith that got too big and was broken up
- Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
文章接著有兩個猜測，試著去解釋為什麼。
第一點可能的原因是 Yagni (You Aren't Gonna Need It)，在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜，快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多，而且可以快速修改。
第二點分成兩個現象：第一個現象是，即使是對產品的商業領域很有經驗的資深架構師，也很難一開始就切出正確的 BoundedContext；第二個現象是，在 microservice 裡，改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。
文章接著想要提出一些建議，在一開始使用 monolith 可以注意的方向，這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。
第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式，當想要切換到 microservice 的時候就有機會比較簡單。
第二種是更常見的方式，一開始先是 monolith 架構，然後把 boundary 好切割的拆成 microservice，所以在過度期會是一組不那麼大的 sub-monolith 架構，然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。
第三種方式就是砍掉重練。
第四種方式是一開始的時候不用 monolith，而是幾個很大包的 service (所以一開始不太能叫 microservice)，當商業模式成熟穩定後，切出更細緻的 boundary 的時候再拆成 microservice。
把這篇文章拿去搜尋 Hacker News 上的討論，可以看到除了 2021 年的這次討論外，在 2017 年的時候就有一批討論也蠻有趣的，可以看到有些不同的風向：「Monolith First (2015) (martinfowler.com)」。
當然也未必要信 Martin Fowler 的看法，軟體工程這塊還是有很多不同的流派...
Stack Overflow 公開了 2016 年現在的系統架構：「Stack Overflow: The Architecture - 2016 Edition」。
Stack Overflow 的重要性可以從前陣子 Twitter 上流傳的一張讓大家笑的很開心的圖看出來：
The one true #JavaScript exception handler. ;) pic.twitter.com/Zwoi3VlluD
— Jordan Hall (@DivineOmega) February 5, 2016
身為目前「程序猿」(!) 最重要的 debug (!!) 資料來源，而且是目前少數用 ASP.NET 與 Microsoft SQL Server 作為網站與資料庫的架構，並且是放在傳統 IDC 機房而非 Cloud Service 的知名網站，大家也很好奇他們是怎麼堆出來的。
上次公開 Stack Overflow 的系統架構是 2013 年年底了 (參考當時寫的「Stack Overflow 的現況...」這篇)，這份更新距離上次兩年多了，也有很多可以交叉比較的事情。
比較有趣的是效能的提昇的說明，本來以為會是說因為我們改善程式碼的效率或是其他類似的理由，結果居然直接說是因為買新機器了 XDDD：
You may be wondering about the drastic ASP.Net reduction in processing time compared to 2013 (which was 757 hours) despite 61 million more requests a day. That’s due to both a hardware upgrade in early 2015 as well as a lot of performance tuning inside the applications themselves.
另外覺得比較有趣的是 Cisco 的 ASR-1001 與 ASR-1001-x，不知道是什麼理由選擇這個系列，改天找 Cisco 的朋友問問看好了...
另外他們的 Websockets 也拿來做有趣的事情：
We use websockets to push real-time updates to users such as notifications in the top bar, vote counts, new nav counts, new answers and comments, and a few other bits.
另外他們也發現有些瀏覽器連線已經連 18 個月了 (喂喂)，也許應該去看一下人是不是還活著：
Fun fact: some of those browsers have been open for over 18 months. We’re not sure why. Someone should go check if those developers are still alive.
我猜是 production server 上開瀏覽器查資料後沒關掉，就一直連著...
在 Baron Schwartz 的 blog 上看到「An Outline for a Book on InnoDB」這篇文章，作者因為被 InnoDB 所驚嘆而想要寫一本書探討 InnoDB 的設計：(因為雖然複雜，但試著將這些複雜的東西隱藏起來，不讓使用的人暈頭轉向)
Years ago I pursued my interest in InnoDB’s architecture and design, and became impressed with its sophistication. Another way to say it is that InnoDB is complicated, as are all MVCC databases. However, InnoDB manages to hide the bulk of its complexity entirely from most users.
I decided to at least outline a book on InnoDB. After researching it for a while, it became clear that it would need to be a series of books in multiple volumes, with somewhere between 1000 and 2000 pages total.
作者還沒開始寫，不過 outline 已經先列出來了：
I did not begin writing. Although it is incomplete, outdated, and in some cases wrong, I share the outline here in case anyone is interested. It might be of particular interest to someone who thinks it’s an easy task to write a new database.
這篇文章的重點在這些 outline，即使沒有寫成書，這些 outline 也讓你知道要可以朝什麼方向研究...
因颱風延期的「COSCUP 2015 Hands-on【妙生活】MySQL 入門」剛好可以 review 這邊的 outline 來修正一些主題。