「ステートフル（Stateful）」と「ステートレス（Stateless）」は、主にシステムやプロトコルが「状態」を保持するかどうかの違いを指す概念です。
という説明はちまたに溢れているので、ざっくりとした例えを使って理解を深めていきましょう。
1.「ステートフル」と「ステートレス」
ステートフル（Stateful）
状態の保持:
サーバー側がクライアントとの過去のやり取りやセッション情報を記憶します。
| 特徴 | 説明 |
|---|---|
| 継続性 | 複数のリクエストにまたがる一連の処理が可能になる。 |
| 利便性 | ログイン状態の維持や、ECサイトでの買い物かごの内容保持など、ユーザーに合わせたカスタマイズやワークフローを実現しやすい。 |
デメリット
スケーラビリティが低い:
サーバーが状態を保持するため、サーバーを増やして負荷を分散させるのが難しくなりやすい。
特定のクライアントのセッション情報を保持しているサーバーに、常にそのクライアントからのリクエストを送信させる必要が出てくるためです。
リソース消費:
セッション情報を管理するために、メモリや処理能力を消費します。
例え
ざっくり例え(ステートフル（Stateful）なレストラン)
1回目の注文: 「ハンバーガーをください」
ウェイター: 「承知しました」
2回目の注文: 「それと、ポテトも」
ウェイター: 「ハンバーガーに加えてポテトもご注文ですね」
このように、ウェイター（サーバー）があなたの過去の注文（状態）を記憶しているため、「それと」のような前の文脈に依存した注文が可能です。
デメリット
- ウェイターはあなたのテーブル（セッション）に常に気を配る必要がある（リソース消費）。
- そのウェイターが他の仕事で手一杯になったとしても、別のウェイターはあなたの注文を把握していないため、スムーズに引き継げません（スケーラビリティが低い）。
ステートレス（Stateless）
状態の非保持:
サーバー側は、クライアントからのリクエストごとに完結した処理を行う。過去のやり取りは一切記憶しない。
| 特徴 | 説明 |
|---|---|
| 独立性 | 各リクエストが独立しているため、どのサーバーが処理しても同じ結果が得られる。 |
| スケーラビリティ | 複数のサーバーにリクエストを分散させやすく、システムを拡張しやすい。 |
デメリット
冗長な情報:
各リクエストに必要な情報を毎回含める必要があるため、ネットワークのトラフィックが増加する可能性がある。
複雑な処理への不向き:
複数のリクエストを関連付けた複雑なワークフローを構築するのが難しい場合がある。
例え
ざっくり例え(ステートレス（Stateless）なレストラン)
1回目の注文: 「ハンバーガーをください」
ウェイター: 「承知しました」
2回目の注文: 「それと、ポテトも」
ウェイター: 「それと？って何ですか」
2回目の注文: 「あー。ハンバーガーに加えて、ポテトも」
ウェイター: 「ハンバーガーに加えてポテトもご注文ですね」
この方式では、どのウェイターでも同じように対応できるため、お客さんが増えてもウェイターの数を増やすだけで対応できます。つまり、拡張性（スケールアウト）に優れています。
しかし、ウェイターは毎回違う人が担当し、あなたのことを一切覚えていません。
デメリット
毎回「ハンバーガーに加えて」という情報を含める必要があります。（通信の冗長性）
2. まとめ
今回の内容をまとめてみました。
| 項目 | ステートフル（Stateful） | ステートレス（Stateless） |
|---|---|---|
| 状態の保持 | する | しない |
| リクエストの独立性 | リクエスト間に前後関係がある | 全てのリクエストが独立している |
| 主な用途 | ログインセッション、ショッピングカート、チャットなど、継続的なやり取りが必要なシステム | 単純なデータ取得、Webページの閲覧、REST APIなど |
| スケーラビリティ | 拡張が難しい | 拡張しやすい |
| 例 | ECサイト、オンラインゲーム | 検索エンジン、Webサイトの単一ページの表示 |
3. 最後に
ステートフルなのか、ステートレスなのかで優劣はありません。用途によって使い分けられ、そしてWeb技術の根幹になっているという認識をもつ必要があります。