システム設計は君の個性じゃない

Twitterのエンジニアリングインフルエンサー全員がシステム設計図を投稿している。ロードバランサーがマイクロサービスを指し、メッセージキューを指し、分散キャッシュを指す。箱と矢印だらけ。

一方、彼らの実際の本番システムは単一のEC2インスタンス上のDjangoモノリスだ。そしてちゃんと動いている。

システム設計産業複合体

システム設計コンテンツを中心に業界全体が構築されている。「Netflixが10億リクエストをどう処理するか」を解説するYouTube動画。「ゼロからTwitterを設計する」LinkedInポスト。箱の中にKafkaを描く方法を教えるのに$500請求する面接対策コース。

誰も言わないこと：ほとんどのエンジニアはそのスケールのシステムを絶対に作らない。

スタートアップには1,000ユーザー。Kafkaはいらない。サービスメッシュもいらない。誰もプロダクトを使っていないときに「スケールのために設計」する必要もない。

でもシステム設計コンテンツは中毒性がある。賢くなった気がする。アーキテクチャ図を描くのは、3週間失敗し続けてるフレーキーなテストを直すより楽しい。

知識-行動ギャップ

CAP定理、コンシステントハッシング、分散合意のリーダー選出を説明できる候補者を面接した。ホワイトボードスキル：完璧。

それからシンプルなレートリミッターの実装を頼んだ。フリーズした。

20行。99%のユースケースで動く。Redisは不要。

実装スキルなしのシステム設計知識は、ただのトリビアだ。

システム設計が本当に重要なとき

システム設計が無駄だとは言わない。重要なとき：

• 実際にスケールしているとき（毎日数百万ユーザー、「いつかスケールするかも」ではない）
• 不可逆なインフラ決定を下しているとき
• すでに分散システムを持っている会社に入るとき
• FAANGで面接するとき（ゲームだ、プレイしろ）

でもエンジニアリング仕事の他の95%では？ただ作れ。 痛かったらリファクタリングしろ。必要になったらスケールしろ。ほとんどの「スケーリング問題」は実際「誰も使ってない」問題だ。

本当のスキルギャップ

みんながシステム設計を勉強している間、これらのスキルは実際に不足している：

本番問題のデバッグ。 ログを読む、リクエストをトレースする、深夜3時に干し草の山から針を見つける。どんな図もここでは助けにならない。

メンテナブルなコードを書く。 チームメイトが理解できるコード。6ヶ月後の自分が理解できるコード。退屈で、過小評価されて、必須。

一貫してリリースする。 仕事を小さなピースに分ける。1日に複数回デプロイ。3ヶ月「アーキテクチャ」に費やさない。

ビジネスを理解する。 何のために作っているか知る。スコープを容赦なく削る。オーバーエンジニアリングの代わりに「それはいらない」と言う。

これらはシステム設計面接に出てこない。すべて実際の仕事ではより重要だ。

私の見解

面接のためにシステム設計を勉強しろ。既知のルールを持つゲームだ。

でも面接対策とエンジニアリングスキルを混同するな。100同時ユーザーを扱うサイドプロジェクトを一度も作ったことがないのに、「Uberを設計する」動画を何時間も見るな。

まず何かをリリースしろ。壊れたらスケールしろ。

私が最も尊敬するエンジニアは、最高のアーキテクチャ図を持っている人ではない。みんながメッセージキューの選択を議論している間に動くソフトウェアをリリースした人だ。

---

システム設計は重要だ。リリースはもっと重要だ。

— blanho