Twitterのエンジニアリングインフルエンサー全員がシステム設計図を投稿している。ロードバランサーがマイクロサービスを指し、メッセージキューを指し、分散キャッシュを指す。箱と矢印だらけ。
一方、彼らの実際の本番システムは単一のEC2インスタンス上のDjangoモノリスだ。そしてちゃんと動いている。
システム設計コンテンツを中心に業界全体が構築されている。「Netflixが10億リクエストをどう処理するか」を解説するYouTube動画。「ゼロからTwitterを設計する」LinkedInポスト。箱の中にKafkaを描く方法を教えるのに$500請求する面接対策コース。
誰も言わないこと:ほとんどのエンジニアはそのスケールのシステムを絶対に作らない。
スタートアップには1,000ユーザー。Kafkaはいらない。サービスメッシュもいらない。誰もプロダクトを使っていないときに「スケールのために設計」する必要もない。
でもシステム設計コンテンツは中毒性がある。賢くなった気がする。アーキテクチャ図を描くのは、3週間失敗し続けてるフレーキーなテストを直すより楽しい。
CAP定理、コンシステントハッシング、分散合意のリーダー選出を説明できる候補者を面接した。ホワイトボードスキル:完璧。
それからシンプルなレートリミッターの実装を頼んだ。フリーズした。
20行。99%のユースケースで動く。Redisは不要。
実装スキルなしのシステム設計知識は、ただのトリビアだ。
システム設計が無駄だとは言わない。重要なとき:
でもエンジニアリング仕事の他の95%では?ただ作れ。 痛かったらリファクタリングしろ。必要になったらスケールしろ。ほとんどの「スケーリング問題」は実際「誰も使ってない」問題だ。
みんながシステム設計を勉強している間、これらのスキルは実際に不足している:
本番問題のデバッグ。 ログを読む、リクエストをトレースする、深夜3時に干し草の山から針を見つける。どんな図もここでは助けにならない。
メンテナブルなコードを書く。 チームメイトが理解できるコード。6ヶ月後の自分が理解できるコード。退屈で、過小評価されて、必須。
一貫してリリースする。 仕事を小さなピースに分ける。1日に複数回デプロイ。3ヶ月「アーキテクチャ」に費やさない。
ビジネスを理解する。 何のために作っているか知る。スコープを容赦なく削る。オーバーエンジニアリングの代わりに「それはいらない」と言う。
これらはシステム設計面接に出てこない。すべて実際の仕事ではより重要だ。
面接のためにシステム設計を勉強しろ。既知のルールを持つゲームだ。
でも面接対策とエンジニアリングスキルを混同するな。100同時ユーザーを扱うサイドプロジェクトを一度も作ったことがないのに、「Uberを設計する」動画を何時間も見るな。
まず何かをリリースしろ。壊れたらスケールしろ。
私が最も尊敬するエンジニアは、最高のアーキテクチャ図を持っている人ではない。みんながメッセージキューの選択を議論している間に動くソフトウェアをリリースした人だ。
システム設計は重要だ。リリースはもっと重要だ。
— blanho
# 勉強したこと
"分散レート制限シナリオでは、Redisクラスターの
パーティショニング、スライディングウィンドウアルゴリズム、
結果整合性のトレードオフを考慮する必要が..."
# 実際に仕事で必要だったもの
from collections import defaultdict
import time
class RateLimiter:
def __init__(self, max_requests, window_seconds):
self.max_requests = max_requests
self.window = window_seconds
self.requests = defaultdict(list)
def is_allowed(self, user_id):
now = time.time()
# 古いリクエストをクリーン
self.requests[user_id] = [
t for t in self.requests[user_id]
if now - t < self.window
]
if len(self.requests[user_id]) < self.max_requests:
self.requests[user_id].append(now)
return True
return False