前回は、1つの出来事を、関係する複数の相手へ一斉に知らせる という話を見ました。

前回のメッセージキューは、
1つの仕事を誰か1人が処理する話でした。

今回の Pub・Sub は、
1つの出来事を複数の相手が受け取って、それぞれ動く話でした。

今回は、その続きです。

テーマは、Dead Letter Queue です。

一言でいうと、何度見ても処理できないメッセージを、本流からいったん切り離して別で扱う という話です。

📌 この記事でわかること

今回は、Dead Letter Queue の入口を見ていきます。

なぜ「失敗したら何度もやり直す」だけでは危ないのか
本流に置き続けると何が起きるのか
Dead Letter Queue が何を守っているのか
なぜ「捨てる」のではなく「隔離する」のか

まずは細かい設定よりも、どうしても処理できないものを本流に置きっぱなしにすると、全体が詰まることがある という感覚をつかむのが目的です。

🐣 レストランでの出来事

メッセージキューを導入してから、厨房はかなり回るようになっていた。

ホールは注文票を書いて並べる。
シェフは手が空いたら、上から順に取って作る。

前よりずっと平和だった。

でも、ある日の夜だった。

シェフ：ちょっと待て

僕：どうしました？

シェフが手にしていた注文票には、こう書かれていた。

注文：美味しいやつ。いい感じで。あと、夢があるやつ。

僕：なんですかこれ……

シェフ：知るか！！！

シェフ：こんなの、確認しないと作れねえよ！！！

シェフはその注文票を、調理台の横に置いた。

僕：じゃあ、それは後で確認ですか？

シェフ：そうだ

シェフ：いったん横に避ける

シェフは次の注文票を取った。

普通のオムライスだった。
それはすぐ作れた。

でも、その次も、そのまた次も、変な注文票が混ざり始めた。

辛くないけど辛い感じのパスタ
光る前菜
できれば空を飛べるデザート

シェフ：なんなんだ今日は！！！

僕：やばいですね……

気づけば、厨房の横は「確認待ち」の注文票だらけになっていた。

普通の注文票と混ざり始めて、
どれが今すぐ作るものか、どれが確認待ちか、だんだん分からなくなってきた。

シェフ：うわっ

シェフ：さっきのハンバーグ、どこ行った！？

僕：あっ

僕：確認待ちの紙に埋もれてますね……

先輩：これが一番まずい状態です

僕：え？

先輩：一時的に確認が必要な紙なら、横に避けてあとで聞けばいいんです

先輩：でも、何度見ても作れない注文票 を本流のすぐ横に積み続けると、まともな注文まで埋もれ始めます

僕：なるほど……

僕：つまり、確認待ちが本流の流れを壊してるんですね

先輩：そうです

そのとき、店長が黄色い箱を持ってきた。

店長：だったら、確認待ちはこの箱に入れろ

僕：箱？

店長： 2回、3回見ても意味が分からない注文は、本流の列から外してこの箱へ移す！

店長：そうすれば、まともな注文はそのまま流せるだろ！

僕：あっ……

僕：なるほど！

僕：捨てるんじゃなくて、いったん別の場所へ隔離するんですね

先輩：そうです

先輩：そうすれば本流は守れるし、あとで落ち着いて中身を確認できます

僕：たしかに……

僕：詰まりを防ぎつつ、原因調査もできるんですね

先輩：そういうことです

その瞬間、僕は少しだけ腑に落ちた。

大事なのは、
分からないものを何でも本流の近くに積み続けること
ではなかった。

処理できないものは、本流から切り離して別で管理すること。
今日は、その意味が見え始めた日だった。

📝 システムデザインにおきかえると

今の話が、そのまま Dead Letter Queue（DLQ） の入口です。

ここで大事なのは、処理に失敗したメッセージを何でも本流に残し続けると、全体の流れまで悪くなることがある ということです。

1️⃣ そもそも何が問題なのか

メッセージ処理では、失敗したらすぐ捨てるのではなく、もう一度やり直すことがよくあります。

たとえば、

一時的に通信に失敗した
相手のサービスが少しだけ落ちていた
たまたまDBが重かった

みたいなケースなら、あとで再試行すれば成功することがあります。

これは大事な考え方です。

でも問題は、何度やっても成功しないメッセージ があることです。

たとえば、

形式が壊れている
必須データがない
中身が意味不明で処理不能

みたいなものです。

こういうメッセージを本流の近くに置き続けると、正常な処理まで巻き添えになります。

2️⃣ Dead Letter Queue って何？

Dead Letter Queue は、かなりざっくり言うと、何度も失敗したメッセージを隔離するための別キュー です。

レストランでいえば、

普通の注文は本流の注文列で処理する
でも、何度見ても意味が分からない注文票は、別の黄色い箱へ移す

という形です。

つまり、本流を守るために、問題のあるメッセージを別で扱う わけです。

3️⃣ 何がうれしいのか

DLQ の強みは、かなり分かりやすいです。

① 本流の詰まりを防げる

処理不能なメッセージを本流の近くに置き続けないので、後ろの正常な処理を流し続けられます。

② 問題のあるメッセージを見失わない

ただ捨てるのではなく、別の場所へ残しておけます。

だから、あとで

何が壊れていたのか
なぜ失敗したのか
手動で救えるのか

を調べられます。

③ 「一時的な失敗」と「構造的に無理」を分けられる

数回はリトライする。
でも、それでもダメなら本流から外す。

この線引きができるのが大きいです。

4️⃣ なぜ「捨てる」ではだめなのか

ここも大事です。

「どうせ失敗するなら捨てればいいじゃないか」と思うかもしれません。

でも、それをやると

バグの証拠
想定外の入力
本当は救えたかもしれないデータ

まで消えてしまいます。

レストランでいえば、意味不明な注文票を破って捨ててしまったら、

誰が書いたのか
本当に読み間違いだったのか
受付ミスだったのか

が後から分からなくなります。

だから DLQ は、捨てる箱ではなく、調査のための隔離場所 と考えたほうが分かりやすいです。

5️⃣ どんなときに使うのか

かなりざっくり言うと、DLQ はこんな場面で強いです。

場面	何が助かるか
一部の壊れたメッセージが混ざる	本流の処理を止めずに済む
あとで原因調査したい	問題のメッセージを残せる
手動復旧や再投入を考えたい	隔離後に落ち着いて対応できる

逆に大事なのは、DLQに入れたら終わりではない ことです。

なぜ入ったのか監視する
原因を直す
必要なら再処理する

ところまで考えないと、本当の解決にはなりません。

6️⃣ この回で本当に大事なこと

この回で一番大事なのは、Dead Letter Queue は「処理できないメッセージを捨てるため」ではなく、「本流を守りながら、あとで調査できるように隔離するため」の仕組み だということです。

失敗したら、まずはリトライする。
でも、何度やっても無理なら、本流に置き続けない。

別の場所へ避難させて、全体の流れを守る。

一言でいうと、

Dead Letter Queue は、「問題のあるメッセージを、本流を止めずに切り離すための安全装置」
なのです。

🎭 今回のオチ

僕：なるほど……

僕：作れない注文を本流に残し続けると、全体が詰まるんですね

先輩：そういうことです

そのとき、シェフが隔離箱の注文票を1枚持ち上げた。

シェフ：ん？

シェフ：この字、店長の字じゃないか？

僕：えっ

店長：ギクッ

僕：まさか……

シェフ：お前のいたずらか！！！

店長：ギクッ !!!