非同期処理・キャッシュ・リアルタイム

メール送信・画像の変換・外部 API への通知・CSV の書き出しなど、時間がかかる処理や失敗しやすい処理は、リクエストの中で行わずキューにジョブとして入れ、別のプロセス（ワーカー）が後で処理します。ユーザーへの応答が速くなり、外部が落ちていてもリクエストは失敗しません。

ジョブの失敗とリトライ・デッドレター

• リトライ：失敗したら指数バックオフで数回やり直す。直らない失敗（データが壊れている）はすぐ諦める。
• デッドレターキュー（DLQ）：上限まで失敗したジョブを別のキューに移し、捨てずに残す。件数を監視し、原因を直してから再投入する。
• 冪等にする：多くのキューは「少なくとも1回」届ける（同じジョブが2回動くことがある）ので、2回動いても結果が同じになるように作る（送信済みの記録を見る、一意制約）。
• DB と一緒に：「注文を保存してからジョブを入れる」の間で落ちるとずれる。コミットした後に入れる、または同じ DB の表にイベントを書いて別の処理で送る（Outbox パターン）。
• ジョブには ID など最小限だけを入れ、処理のときに DB から最新を読む。タイムアウトと同時実行数の上限も決める。

「注文を DB に保存して、確認メールのジョブをキューに入れる」は、2つの別のシステムへの書き込みです。間で落ちると、注文はあるのにメールが出ない、逆にジョブはあるのに注文がない（ロールバックされた）というずれが起きます。

どの方法でも、受け取る側は同じジョブが2回来ても大丈夫なように作ります。

SRE の「メッセージングの配信保証」

アプリのキャッシュは、DB や外部 API の結果を Redis やメモリに一時的に置き、同じ問い合わせを速く返す仕組みです。速くなる代わりに、古いデータを返す可能性を受け入れることになります。

Cache-aside と Write-through

async function getUser(id) {
  const hit = await redis.get(`user:${id}`);
  if (hit) return JSON.parse(hit);
  const user = await db.user.findUnique({ where: { id } });
  await redis.set(`user:${id}`, JSON.stringify(user), { EX: 300 });
  return user;
}
// 更新したら消す（書き換えるより消すほうがずれにくい）
await db.user.update(...); await redis.del(`user:${id}`);

消し忘れに備えて TTL（期限）は必ず付けます。ユーザーごとに違うデータは、キーにユーザー ID を入れて混ざらないようにします。

Redis の使い方

SRE の「キャッシュ戦略の全体設計」

Redis などのキャッシュに DB の結果を置くと、DB への問い合わせは大きく減ります。その結果、DB の台数や性能は「キャッシュが効いている前提」の大きさで決まっていることが多く、キャッシュが一斉に消えると、DB はふだんの何倍ものリクエストを一度に受けることになります。

これがスタンピード（キャッシュの一斉失効）です。アクセスの多いサービスでは実際によく起きる障害で、キャッシュの設計を聞かれたときに一緒に答えられるようにしておきます。

アクセスの多いキーの期限が切れた瞬間、大量のリクエストが同時に「キャッシュにない」と判断して DB に殺到し、DB が倒れることがあります。

• TTL をばらつかせる：300 秒 ± ランダムにして、同時に切れないようにする。
• 1人だけ作り直す：ロック（SET key NX PX）を取った1つのリクエストだけが DB を読み、他は少し待つか古い値を返す。
• 期限前に裏で更新：期限が近づいたら古い値を返しつつ、裏で作り直す（stale-while-revalidate の考え方）。

下の「ブラウザで試す」の図は、前半でキャッシュの基本の使い方（まず Redis を見る → なければ DB から読んで TTL 付きで入れる → 次はヒット → 更新したらキャッシュを消す）を追います。このトピックの話は後半で、人気のキー（hot:ranking）の TTL が切れた瞬間に多くのリクエストが同時に DB へ向かう様子と、SET NX でロックを取れた1つだけが作り直す対策を見られます。最後の「Redis が落ちたら」も、全部のリクエストが DB に行くという点で同じ形の障害です。

Redis は、データをメモリに置く「キー → 値」のデータストアです。1回の読み書きが 1ms 未満と速く、値には文字列のほかにハッシュ・リスト・セット・ソート済みセット・ストリームなどの型があります。Web のバックエンドでは、DB の前に置くキャッシュのほか、セッション・レート制限・ランキング・ジョブのキュー・分散ロックによく使います。

知っておくべき性質：Redis はコマンドを1つずつ順番に処理するので、1つ1つのコマンドは原子的（INCR が数え間違えない）ですが、KEYS * のような重いコマンドは全員を待たせます。データはメモリにあるので、上限（maxmemory）と、溢れたときの方針（maxmemory-policy）を決めておきます。キャッシュは「消えても DB から作り直せる」データだけを置くのが基本です。

運用（永続化・レプリケーション・メモリ・監視）は SRE の「Redis の運用」で。

HTTP は、クライアントが聞いてサーバーが答える形なので、そのままではサーバーの側から「新しいメッセージが来ました」と送り出せません。チャットや通知を作るときは、この制約をどう回避するかで方式を選びます。

選んだ方式は、サーバーの負荷・ロードバランサーの設定・再接続の作り方にまで影響します。設計面接でも、なぜその方式にしたかを聞かれます。

チャット・通知・共同編集・進み具合の表示など、サーバーから画面へすぐ届けたいときの方式です。

サーバーから送るだけなら SSE が HTTP のまま使えて簡単です。WebSocket は再接続や生存確認（ping）を自分で作る必要があり、ロードバランサーのタイムアウト設定にも気をつけます。

下の「ブラウザで試す」の図では、5秒ごとに聞くポーリング、GET をつなぎっぱなしにする SSE、HTTP の Upgrade で WebSocket に切り替えて 101 が返り、両方向にメッセージを送る流れ、の順に見られます。最後の手順では、ロードバランサーがしばらく通信のない接続を切るので、サーバーが ping を送って接続を保つことが出てきます。上の「WebSocket は生存確認を自分で作る・ロードバランサーのタイムアウトに気をつける」が、この部分です。

WebSocket や SSE のように接続をつなぎっぱなしにする方式は、サーバーが1台のうちは素直に動きます。ところが、ロードバランサーの後ろでサーバーを2台、3台と増やすと、「送りたい相手が、別のサーバーにつながっている」という問題が出てきます。

チャット・通知・共同編集を本番で動かすには避けて通れない点で、設計面接でも「台数を増やしたらどうするか」はよく聞かれます。

接続はそれぞれ1台のサーバーにつながっています。ユーザー A がサーバー1、B がサーバー2につながっているとき、サーバー1で起きたメッセージは、そのままでは B に届きません。

• Pub/Sub で全台に配る：Redis の Pub/Sub などに流し、全サーバーが受け取って、自分につながっている相手に送る（Socket.IO の Redis アダプターなど）。
• マネージドサービス：API Gateway の WebSocket、Pusher・Ably などに接続の管理を任せる。
• デプロイのときは全接続が切れるので、クライアントは指数バックオフで再接続し、切れていた間の取りこぼしを API で取り直す。

接続を張りっぱなしにする方式は、1台あたりの接続数（ファイルディスクリプタ・メモリ）にも上限があります。負荷試験では同時接続数も測ります。

下の「ブラウザで試す」の図では、A さんがサーバー A、B さんがサーバー B に WebSocket でつながった状態から、A さんのメッセージが Redis の PUBLISH で全台に配られ、サーバー B から B さんに届くまでを追えます。LB が Upgrade を中継して接続を保ったままにすること、1台が持てる接続の上限に続いて、デプロイでサーバー B が Close（1001）で接続を閉じたあと、B さんが指数バックオフで再接続し、最後に受け取った ID より後のメッセージを DB から取り直すところまで、上の対策を手順で確かめられます。