🍝 4回. レストランが大繁盛！そのときシステムはどうする？
ついにうちのレストランが大人気になりました！
口コミが広がり、店の前にはお客様の長い列。
多くの人に美味しい料理を届けられるのは嬉しいことですし、売上も伸びます。
でも、ここで新たな問題が…
――「席数」には限りがあり、すべてのお客様を一度に受け入れることはできません。
結果、待ちきれずに帰るお客様も出てきます。
これはWebサービスでいうと、
「ページがなかなか表示されない」「サーバーから応答がなく離脱する」状況と同じです。😢
😩 トラフィック急増！サーバーが持たない
「じゃあサーバーを増やせばいいんじゃない？」
たしかに有効な方法です。
でも、実際はそんなに簡単じゃありません。
店舗拡張＝インフラ拡張、
キッチン（サーバー）も増設し、
スタッフ（開発リソース）も増やす――
これには時間もコストもかかります。
いますぐお客様（ユーザー）を逃したくはない…
でも無限にサーバー増強はできない…
じゃあどうする？
🧾 待機番号（整理券）システムの登場
レストランで考えてみましょう。
「今すぐご案内できなくても、整理券をお渡しして、
席が空いたら順番に呼びましょう！」
――とてもスマートな方法です。
お客様は整理券を受け取り、
近くで過ごしたり、用事を済ませて戻れる。
お店側も、確実に席が空くたびに順番通り案内できます。
こうして「リクエスト（注文）」が一度に殺到しても、
レストラン（サーバー）は余裕を持ってさばけます。
この役割を担うのが、
開発の世界ではRedisです。
⚡ Redis ― “超記憶力のある待機管理スタッフ”
Redisは、まるで頭の回転が速くて記憶力抜群なスタッフのようです。
お客様が来店するたび、超高速で整理券を発行し、
「今、何番のお客様をご案内中か」
「あと何組が待っているのか」を即座に把握できます。
なぜこんなに速いのか？
Redisはデータをディスクではなく**メモリ（RAM）**に保持するからです。
つまり“頭の中ですぐ答えられる情報”だけを扱うイメージ。
- 待機番号管理
- 現在の案内番号
- 待ち行列一覧
のようなリアルタイムで頻繁に変わるデータ管理に最適です。
例を見てみましょう 👇
| 状況 | Redisの役割 |
|---|---|
| お客様来店 | 新しい番号発行（INCR） |
| お客様入店 | 待機リストから除外（LPOP） |
| 自分の順番確認 | 現在の番号取得（GET） |
Redisはすぐにこう答えます：
「今は3組目をご案内中、次は4番さんです！」
0.001秒で返事するスタッフのような存在です。
🧊 DBとRedisは役割が違う！
「MySQLみたいなDBに全部記録しちゃダメ？」
それも可能ですが、効率的ではありません。
DBは注文履歴や決済情報など、“長期的に残すべき情報”の保存に最適。
でも、整理券のように「短時間で頻繁に変化するデータ」をDBで管理すると
処理速度が低下し、サーバー負荷も増します。
だから――
- DB：売上記録やレシートなど“帳簿”
- Redis：「今の待ち状況」を映す“電光掲示板”
DBは永続的なデータ保存、
Redisは短期間でよく変わるデータの超高速処理。
この役割分担によって、Webサービスは効率よく動きます。
🧩 組み合わせて使うのが最強
実際はRedis＋DBを「併用」します。
Redisで“今の状態”を瞬時に見せて、
DBで“最終結果”を安全確実に記録。
具体例：
- Redis：現在の待機人数25人
- DB：本日合計来店客132人
このように分担することで、
システムは速さと安定性の両立が可能となります。
🚀 まとめ
お客様が増えるほど「待機列管理」は重要です。
そんなときRedisは、
高速に変化する情報を扱う即応型システムとして大活躍します。
レストランの整理券と同じように、
ユーザーも無駄に待たずサービスを利用できる――
その結果、Webサービスはよりスムーズになり、
お客様（ユーザー）の満足度も向上します。
🍰 次回予告
待機列はスムーズに処理できました！
でも店内はお客様で溢れ、今度は注文数急増でキッチンがパンク寸前…。
次回はキャッシュ(Cache)について、
実例を交えながら一緒にみていきましょう！