1001人目のユーザーが
登録できない日
「そんなにユーザーは来ないだろう」という開発者の予言は外れ、サービスはバズりました。
しかし、歓喜の中でシステムは静かに新規登録ボタンを無効化しました。
コードの中に埋め込まれた「見えない天井」が、成長を物理的に阻んだのです。
- 「IDは4桁もあれば足りる」と言って `SMALLINT` を使っている
- ファイルアップロードの上限がサーバー初期設定のまま（2MB）である
- ページネーション（ページ送り）がなく、1画面に全データを表示しようとする
- 2038年問題（Unix Timeの桁あふれ）について考えたことがない
ビジネスが軌道に乗った瞬間に、自壊するようにプログラムされています。
01. 甘いお見積りの代償
配列のサイズ固定 `users[1000]`。DBの `VARCHAR(20)`。ページング処理の欠如。
これらはすべて、「未来の成功」を信じていない証拠です。
特に恐ろしいのは、システムがエラーを出さずに「ただ静かにデータを切り捨てる」ケースです。
気づいた時には、貴重な顧客データがデータベースに入りきらず、電子の藻屑となっています。
「明日100倍の客が来ても平気な顔をする」ことだ。
02. マジックナンバーを排除せよ
コードの中に直接数字（マジックナンバー）を書くのはやめましょう。
`if (count > 100)` ではなく、設定ファイルや定数 `MAX_DISPLAY_COUNT` として定義する。
それだけで、「制限の緩和」はコード修正から設定変更へと変わり、ビジネスのスピードに対応できるようになります。
03. ID枯渇問題
Twitter（現X）もInstagramも、初期はIDの桁数不足に苦しみました。
データベースの主キーには、最初から `BIGINT`（あるいはUUID/ULID）を使うべきです。
「40億もデータはいかない」と笑う前に、40億件データが来た時の利益を想像し、それに備えるのがエンジニアの仕事です。