導入
注文処理システムで、注文を受け付けるWebサーバーと、注文を処理するバックエンドを直接つなぐとどうなるでしょうか。バックエンドが落ちていたら注文も受け付けられません。バックエンドの処理が遅ければWebサーバーも詰まります。この「直結による共倒れ」を防ぐのが 疎結合（Loose Coupling） という考え方です。
説明
Amazon SQS（Simple Queue Service） は、コンポーネント間に キュー（メッセージの待ち行列） を挟むフルマネージドサービスです。送信側はキューにメッセージを置くだけ、受信側は自分のペースでキューから取り出して処理します。両者は互いの状態を知る必要がなく、一方が落ちても他方は影響を受けません。
flowchart LR
P["注文を受け付けるWebサーバー<br/>（プロデューサー）"] -->|"メッセージを送信"| Q["SQSキュー"]
Q -->|"自分のペースで取得"| C["注文処理バックエンド<br/>（コンシューマー）"]
急なアクセス集中があっても、キューがメッセージを溜め込んで バッファ の役割を果たすため、バックエンドは自分の処理能力の範囲でゆっくり処理できます（スパイク吸収）。
SQSには2種類のキューがあります。
| 種類 | 特徴 | 使いどころ |
|---|---|---|
| 標準キュー（Standard） | ほぼ無制限のスループット、順序は保証されない、まれに重複配信 | とにかく大量・高速に処理したい（順序不問） |
| FIFOキュー | 送信順を厳密に保証、重複排除、スループットに上限あり | 注文処理など「順番」が重要な処理 |
覚えておくべき重要な仕組みが2つあります。
- 可視性タイムアウト（Visibility Timeout）：あるコンシューマーがメッセージを取得すると、そのメッセージは一定時間「他のコンシューマーから見えなく」なります。処理が時間内に完了しないと、メッセージは再びキューに戻り、二重処理のリスクが生まれます。
- デッドレターキュー（DLQ）：規定回数処理に失敗し続けたメッセージを隔離する、専用の別キューです。「処理できないメッセージ」がキューに滞留して他の処理を妨げるのを防ぎます。
読んでみよう
「システムを疎結合にしたい」「トラフィックのスパイクをバッファリングしたい」「一部の障害を全体に波及させたくない」——これらのキーワードが出たらまずSQSを検討してください。「順序が重要」ならFIFOキュー、「処理に何度も失敗するメッセージを隔離したい」ならDLQ、と覚えましょう。