バックエンドサーバ — 「何を返すか」を考える頭脳

バックエンドは、フロントからの要求を受けて業務ロジックを実行し、データ層を操作して結果を返すサーバです。設計の要点は次の3つ。

• API の形 — REST（リソース単位）や GraphQL（必要な形で取得）など、決まった規約で会話する
• ステートレス — サーバ自身に会話の状態を持たせない。状態はトークン・DB・キャッシュへ逃がす
• 認証・認可 — 認証（誰か）はトークンやセッションで、認可（何ができるか）はロールや権限で

登場人物メモ:

• ※1 REST／GraphQL — 代表的なAPIの形。前者はURL単位、後者は問い合わせ言語
• ※2 トランザクション — 「全部成功か、全部なかったことにするか」をまとめて扱う単位

1. 入口経由で API リクエストが届く
2. トークン等で認証、ロール等で認可を確認
3. 業務ロジックを実行（必要なら複数の操作をトランザクションでまとめる）
4. DB／キャッシュ／ストレージにアクセス（読みはキャッシュ優先で軽くする）
5. 結果を規約どおりの形（JSONなど）で返す

• 水平スケール — ステートレスにしておけば、混雑時はサーバを増やして分散できる
• キャッシュ戦略 — 読み取りの多い結果はキャッシュに載せ、DB負荷を下げる
• N+1問題 — 一覧＋各行ごとのクエリで本数が爆発する。JOINやまとめ取得で回避
• コネクションプール — DB接続は毎回張り直さず、あらかじめ用意した接続を使い回す。ただし水平スケール時は「サーバ台数×1台あたりのプール数」がDBの接続上限を圧迫する点に注意
• 非同期ジョブ — 重い処理はキューに積み、レスポンスと切り離す

• タイムアウト — 処理が長すぎる。リトライするなら冪等性（何度実行しても同じ結果）に注意
• デッドロック — 複数の処理が互いのロックを待って止まる
• 整合性の乱れ — キャッシュとDBの内容がズレる（無効化の設計が甘い）