本文是跨 vendor migration playbook、cross-link 到 AWS SQS 跟 Google Pub/Sub。這是一個 跨雲 managed-to-managed 遷移：兩端都是 cloud-managed、運維負擔都低、但 資料拓樸 跟 消費抽象 不同 — SQS 是 region-scoped 的單一 pull queue、Pub/Sub 是 global topic + 多個 first-class subscription。主結構走 operational redesign hybrid（Type C）、額外為 components / data topology 兩個高維度抽獨立段。

SQS 跟 Pub/Sub 不是同一種訊息抽象

SQS 跟 Pub/Sub 都是 cloud-managed 非同步訊息服務、都解「解耦 producer / consumer、不自管 broker」這個問題、application 程式碼裡都是「發訊息、收訊息、處理完確認」的形狀。從這層看兩者可互換、遷移像是換 SDK。

差別在 消費抽象 跟 資料拓樸。SQS 的核心實體是 queue：一條 region-scoped 的訊息隊列、訊息被一個 consumer 領走（in-flight）就對其他 consumer 隱形、處理完 DeleteMessage 就消失。要讓同一筆事件送給多個下游、SQS 端的做法是在 SNS 前面 fan-out、再各接一條 SQS queue。Pub/Sub 的核心實體是 topic + subscription 兩層：topic 收訊息、subscription 是 first-class 的消費端點、一個 topic 可掛 N 個 subscription、每個 subscription 各自維護消費進度、fan-out 是模型內建而不是外接。

這個差別決定了遷移的形狀。如果原系統只是「一條 queue、一群 worker 競爭領取」、那 Pub/Sub 端是「一個 topic、一個 pull subscription」、對位乾淨、application 改動小。如果原系統靠 SNS-to-many-SQS 做扇出、那 Pub/Sub 端是「一個 topic、多個 subscription」、整個 fan-out 拓樸要重畫、這不是換 SDK、是重設計訊息流。先判斷自己屬於哪一種、再決定 playbook 的重量。

為什麼會跨雲遷這條路徑

跨雲從 SQS 遷到 Pub/Sub 的 driver 跟同雲 vendor 切換不同、通常不是「Pub/Sub 比 SQS 好」、而是 整體 workload 的重心移到 GCP：

1. 資料平台落在 GCP：下游分析走 BigQuery、streaming 走 Dataflow、容器跑 Cloud Run。事件如果留在 AWS、每筆都要跨雲搬到 GCP 才能進 BigQuery、跨雲 egress 費用跟延遲都是常態成本。把訊息層也移到 Pub/Sub、事件可以用 BigQuery subscription 直接落地、省掉中間搬運。
2. 需要 global topic、不想管 region：SQS queue 綁 region、跨 region 要自己複製或在前面架路由。Pub/Sub topic 沒有 region 概念、publish 進去全球可訂閱、多區域服務的事件分發是 first-class。
3. fan-out 從外接變內建：原本靠 SNS + 多條 SQS 維護的扇出拓樸、在 Pub/Sub 是「一個 topic 掛多個 subscription」、少一層 SNS、扇出關係在 subscription 列表一覽。

這三條 driver 都假設 重心已經或即將在 GCP。如果系統長期紮根 AWS、只為了「換個 queue」跨雲、會付出跨雲 IAM 重對位、雙雲計費、跨雲網路延遲的代價、ROI 通常不成立。遷移前先確認 driver 是 workload 重心轉移、不是單純偏好。

結構為什麼是 operational hybrid 加兩個高維度獨立段

寫這篇前先跑 diff dimension audit、6 維評級如下：

主導維度是 operational model（跨雲身份與監控全換）、所以主結構走 Type C operational redesign hybrid。但 components 跟 data topology 也是 High — 不是把它們塞進 operational 段就能講清楚的、消費抽象從「一條 queue」變「topic + 多 subscription」是讀者最容易踩雷的地方。按 migration 方法論的 multi-axis 規則、高維度抽成獨立段補充、不硬塞進單一 type 標籤。所以本篇結構是：operational 對位主軸 + 「消費抽象重設計」獨立段（components / topology 軸）+ 跨雲特有的 IAM 與網路段。

Operational 對位：機制名詞換、語意要逐一確認

跨雲遷移最容易出錯的環節、是 找到語意相近的功能、卻假設行為一致。SQS 跟 Pub/Sub 多數機制都有對位、但每一組都有行為差、找得到對應功能只是第一步。下表先給對照、後面逐項展開語意陷阱。

Visibility timeout → ack deadline

Visibility timeout 跟 ack deadline 都回答同一個問題：consumer 領走訊息後、多久沒確認就視為失敗、把訊息重新投遞。語意對位成立、但兩端的數字與延長機制不同。

SQS visibility timeout 預設 30 秒、上限 12 小時、consumer 要延長就主動呼叫 ChangeMessageVisibility。Pub/Sub ack deadline 預設 10 秒、上限 600 秒（10 分鐘）、而且 client library 預設會 自動 在背景延長 deadline（lease management）。這個自動延長是最容易踩到的差異：在 SQS 端習慣「設一個夠長的 visibility timeout、處理完再 delete」、搬到 Pub/Sub 如果只把 ack deadline 設成 600 秒上限、卻沒意識到 client library 在背景幫忙延長、長任務的行為會跟預期不同；反過來、如果關掉自動延長又設了預設 10 秒、處理稍久就重投。對位的正確做法是先理解 client library 的 lease 行為、再決定 ack deadline 跟 MaxAckPending、而不是把 SQS 的 timeout 數字直接搬過去。

maxReceiveCount / redrive → dead-letter topic

兩端都用「重試 N 次仍失敗就隔離」防止 poison message 阻塞 pipeline、但隔離後的容器不同。SQS 的 DLQ 是另一條 queue、用 maxReceiveCount 控制門檻、修好下游後用 redrive policy 把訊息放回原 queue。Pub/Sub 的 dead-letter topic 是另一個 topic、用 subscription 的 max delivery attempt 控制門檻、超過就 publish 到 DLT。

差別在重處理路徑。SQS redrive 是把 DLQ 訊息搬回 main queue、是一個 queue-to-queue 的搬移動作。Pub/Sub 的 DLT 是 topic、要重處理得在 DLT 上再開一個 subscription 來消費、沒有內建的「放回原 topic」按鈕。Mercari item feed 的案例就是用 DLT 把重試多次仍失敗的訊息隔離、讓後續訊息優先處理、同時把 topic 當突發流量的 load-leveling buffer。從 SQS 搬過來時、redrive 的心智模型要換成「DLT 是一個獨立 topic、重處理是另開 subscription」、不是「按一個按鈕放回去」。設定 DLT 還需要給 Pub/Sub service account 對 DLT 的 publisher 權限跟對原 subscription 的 subscriber 權限、漏設會讓訊息卡住不進 DLT。

Long polling → streaming pull

這一組不是等價對位、是機制不同。SQS long polling 是 consumer 發一個 ReceiveMessage 請求、最多等 20 秒、有訊息就回、沒有就空回、本質仍是 輪詢、只是把空輪詢的頻率降下來省 cost。Pub/Sub 的 pull 在 client library 預設是 streaming pull：consumer 跟 Pub/Sub 建一條長連線、訊息一到就推過來、不是 consumer 反覆問。

對位時不要把 long polling 的「WaitTimeSeconds 20 秒」翻譯成某個 Pub/Sub 參數 — 沒有對應參數、因為機制不同。要關注的是 flow control：streaming pull 因為訊息會主動推來、要用 MaxOutstandingMessages / MaxAckPending 控制同時在處理的訊息量、否則 consumer 會被一次塞太多訊息壓垮。SQS 端「一次拉最多 10 條」的批次節流、在 Pub/Sub 端變成 flow control 設定。Spotify autoscaling 的案例揭露了相關陷阱：下游失敗時 consumer 不 ack 仍持續消耗 CPU、autoscaling 反而把資源越拉越高 — autoscale 訊號要看處理成功率、不是 backlog 加 CPU。

IAM policy → Service Account

跨雲遷移裡、身份模型是 重對位 而不是改語法的部分。SQS 的存取控制是 IAM policy（identity-based、掛在 user / role）加 queue policy（resource-based、掛在 queue）兩層、cross-account 靠這兩層互動。Pub/Sub 是 GCP IAM role（publisher / subscriber / viewer 等）加 Service Account、push subscription 要用 Service Account 認證到目標 endpoint。

兩套身份模型沒有自動轉換工具、要逐條重畫：誰能 publish 對應誰有 topic 的 publisher role、誰能消費對應誰有 subscription 的 subscriber role。跨雲場景還多一層 — 如果遷移期 AWS 端的服務要 publish 到 GCP 的 topic、得用 workload identity federation 或 service account key、讓 AWS 的工作負載拿到 GCP 身份。這部分沒有 case 可引、依 GCP 官方 IAM 文件加最小權限原則設計：每個 service account 只給它實際需要的 role、不要為了遷移方便給 broad role 再說以後收緊、那個「以後」通常不會來。

CloudWatch → Cloud Monitoring

監控訊號要重建、不是改名。SQS 在 CloudWatch 看 ApproximateNumberOfMessagesVisible（queue 深度）跟 ApproximateAgeOfOldestMessage（lag）。Pub/Sub 在 Cloud Monitoring 看 num_undelivered_messages（backlog）跟 oldest_unacked_message_age（最老未確認訊息年齡）。語意相近、但 alarm 邏輯要重寫、而且 Pub/Sub 的 backlog 數字要配合 subscription 維度看 — 同一個 topic 的不同 subscription 各自有 backlog、一個堵住不代表全部堵住。遷移時要把原本對 queue 深度的告警、改成對每個 subscription 的 backlog 與 age 告警。

消費抽象重設計：從一條 queue 到 topic 加多 subscription

這是 components 跟 data topology 兩個高維度的核心、也是從 SQS 搬到 Pub/Sub 最需要重新畫圖的地方。SQS 的世界裡、一條 queue 對應一群競爭領取的 worker；要扇出就在前面架 SNS、SNS 後面接多條 SQS、每條 queue 各一群 worker。Pub/Sub 把這個拓樸壓平：一個 topic 收訊息、掛多少個 subscription 就有多少條獨立的消費流、每個 subscription 各自記進度、彼此不影響。

重設計從盤點現有拓樸開始。先列出：哪些是「單一 queue、一群 worker」的簡單情境、哪些是「SNS fan-out 到多條 SQS」的扇出情境。簡單情境對位乾淨 — 一個 topic、一個 pull subscription、原本競爭領取的 worker 改成同一個 subscription 的多個 consumer、Pub/Sub 自動把訊息分給它們。扇出情境要把 SNS + 多 SQS 換成「一個 topic + 多 subscription」、原本每條 SQS queue 變成一個 subscription、SNS 那一層消失。

扇出情境裡有個方向相反的陷阱要避免：不要把「多個下游」誤設計成「多個 consumer 共用一個 subscription」。同一個 subscription 的多個 consumer 是 競爭 關係、訊息只會給其中一個 — 那是負載分攤、不是扇出。要每個下游都收到完整一份、就要每個下游一個 獨立 subscription。這跟 SQS 端「一條 queue 一個下游、扇出靠 SNS 複製」的直覺方向一致、但實體換了：在 SQS 是多條 queue、在 Pub/Sub 是多個 subscription。畫遷移圖時、SQS 的每條 fan-out queue 一對一映射到 Pub/Sub 的一個 subscription、不要合併。

Application 重設計範例：SQS receive-delete 換成 Pub/Sub pull-ack

 1// SQS 端：long polling receive、處理完 DeleteMessage
 2svc := sqs.NewFromConfig(cfg)
 3for {
 4    out, _ := svc.ReceiveMessage(ctx, &sqs.ReceiveMessageInput{
 5        QueueUrl:            &queueURL,
 6        MaxNumberOfMessages: 10,
 7        WaitTimeSeconds:     20, // long polling
 8    })
 9    for _, m := range out.Messages {
10        process(m.Body)
11        svc.DeleteMessage(ctx, &sqs.DeleteMessageInput{
12            QueueUrl:      &queueURL,
13            ReceiptHandle: m.ReceiptHandle,
14        })
15    }
16}

1// Pub/Sub 端：streaming pull、處理完 Ack、用 flow control 節流
2sub := client.Subscription("orders-sub")
3sub.ReceiveSettings.MaxOutstandingMessages = 100 // flow control、取代「一次拉 10 條」
4err := sub.Receive(ctx, func(ctx context.Context, msg *pubsub.Message) {
5    process(msg.Data)
6    msg.Ack() // 取代 DeleteMessage；client library 在背景自動延長 ack deadline
7})

差異：

• SQS 主動輪詢（ReceiveMessage 迴圈）→ Pub/Sub 回呼模型（Receive 把訊息推進 callback）
• SQS DeleteMessage → Pub/Sub msg.Ack()、語意都是「確認處理完、別重投」
• SQS WaitTimeSeconds 控制輪詢等待 → Pub/Sub MaxOutstandingMessages 控制 flow control
• SQS 一次最多 10 條的批次上限 → Pub/Sub 沒有這個上限、改用 flow control 設同時在途量
• ack deadline 的延長在 SQS 要主動 ChangeMessageVisibility、在 Pub/Sub 由 client library 自動處理

application 邏輯的商業處理部分（process 函式）多數可保留、改動集中在收訊息的框架跟確認語意、估計 20-40% 程式碼。

Production 故障演練

Case 1：fan-out 設計成共用 subscription、下游各收到一部分

徵兆：把原本 SNS fan-out 到 3 條 SQS 的拓樸搬到 Pub/Sub、為了省事建一個 topic + 一個 subscription、讓 3 個下游服務都連這個 subscription。上線後發現每個下游只收到大約三分之一的訊息、不是各收完整一份。

根因：同一個 subscription 的多個 consumer 是負載分攤關係、Pub/Sub 把訊息分給其中一個 consumer、不是每個都送。這對應到 SQS 端「一條 queue 多個 worker 競爭領取」的行為、但被誤用在需要扇出的場景。SQS 端的扇出靠 SNS 複製訊息到多條 queue、那個複製動作在 Pub/Sub 應該由「多個 subscription」承擔、不是多個 consumer 共用一個 subscription。

修法：

1. 每個下游一個獨立 subscription：3 個下游就建 3 個 subscription 掛同一個 topic、每個各收完整一份
2. 遷移圖一對一映射：SQS 的每條 fan-out queue 對應一個 Pub/Sub subscription、不合併
3. 負載分攤跟扇出分開設計：同一下游要多 worker 分攤、是同一 subscription 多 consumer；不同下游各收一份、是多 subscription

Case 2：ack deadline 沿用 SQS 數字太短、長任務反覆重投

徵兆：SQS 端 visibility timeout 設 5 分鐘跑得好好的、搬到 Pub/Sub 隨手把 ack deadline 設成預設或一個小數字、結果處理時間稍長的訊息被反覆重投、同一筆訊息處理多次、下游出現重複副作用。

根因：Pub/Sub ack deadline 預設 10 秒、上限 600 秒、跟 SQS visibility timeout 上限 12 小時差很多。如果關掉 client library 的自動 lease extension、又把 ack deadline 設小、處理時間一超過就被判定失敗重投。SQS 的「設一個夠長的 timeout」直覺搬過來不適用、因為 Pub/Sub 的上限低很多、且延長機制是 client library 自動做。

修法：

1. 理解 client library 的 lease 行為：多數 client library 預設會背景自動延長 ack deadline 到處理完、優先依賴這個而不是手動設超長 deadline
2. 長任務拆短或改架構：單筆處理超過 10 分鐘上限的、考慮拆成多階段或把長任務移出訊息處理路徑
3. 下游做 idempotency：跟 SQS 一樣、Pub/Sub 是 at-least-once、重投本來就會發生、下游用 message ID 去重才是根本解

Case 3：FIFO 順序需求對位到 ordering key、吞吐落差超出預期

徵兆：原系統用 SQS FIFO queue + MessageGroupId 保證同一群訊息順序處理、搬到 Pub/Sub 啟用 ordering key 對位、上線後吞吐比預期低很多、且某些情境順序仍亂。

根因：SQS FIFO 跟 Pub/Sub ordering key 都提供順序、但取捨點不同。SQS FIFO 同時給「順序」跟「5 分鐘去重窗口」、吞吐受限（每 MessageGroupId 串行）。Pub/Sub ordering key 給「同一 key 的訊息按 publish 順序送達」、但要 publish 端跟 subscription 端都正確設定（publish 要設 ordering key、subscription 要 enableMessageOrdering）、漏一邊順序就不保證；而且啟用 ordering 後同一 key 串行、吞吐同樣受限。把 FIFO 的「去重 + 順序」一包功能、誤以為 ordering key 也一包提供、是落差來源。

修法：

1. 拆開「順序」跟「去重」兩個需求：Pub/Sub ordering key 只管順序、去重要 application 端自己用 message ID 做
2. publish 跟 subscription 兩端都設 ordering：缺一邊順序不保證、遷移檢查清單要把兩端都列上
3. 重新評估是否真需要全域順序：FIFO 常被過度使用、很多場景只需要 per-entity 順序、用 ordering key 按 entity 分 key、比強制全域串行吞吐高很多

Case 4：跨雲遷移期雙雲都在跑、egress 成本與延遲被低估

徵兆：漸進 cutover 期間 AWS 跟 GCP 兩邊都在處理訊息、為了對帳把訊息在兩雲之間搬、月底帳單跨雲 egress 費用遠超預估、且跨雲呼叫的尾延遲拖慢端到端處理。

根因：SQS 在 AWS region 內、Pub/Sub 在 GCP、遷移期的 dual publish 或對帳如果讓資料反覆跨雲、每一筆出 AWS 的訊息都計 egress 費。跨雲不只是錢、跨雲網路的延遲跟抖動比同雲高、放在同步處理路徑上會放大尾延遲。同雲 vendor 切換沒有這個維度、跨雲遷移必須把它列進成本模型。

修法：

1. 縮短雙雲並行窗口：dual publish 的對帳期越短越省、設明確的並行截止日、不要無限期雙跑
2. 對帳用抽樣不用全量搬運：驗證一致性用抽樣比對 message ID / count、不要把所有訊息都搬到對面雲比對
3. 生產者就近落點：遷移後讓 producer 直接 publish 到 Pub/Sub、不要繞 AWS 再跨雲、消除穩態的跨雲 egress

Case 5：dead-letter topic 權限沒配齊、毒訊息卡住不進 DLT

徵兆：subscription 設了 dead-letter topic 跟 max delivery attempt、預期重試超限的訊息進 DLT、實際上毒訊息一直在原 subscription 反覆重投、DLT 是空的、後續訊息被堵。

根因：Pub/Sub 要把訊息送進 DLT、是由 Pub/Sub 的 service account 代為 publish 到 DLT topic；同時它也要對原 subscription 有 subscriber 權限才能 ack 掉原訊息。這兩個權限漏任一個、forwarding 到 DLT 就失敗、訊息卡在原 subscription。SQS 端 DLQ 是 queue 屬性、不需要額外給 service 權限、所以這個跨雲差異容易被漏掉。

修法：

1. 配齊 DLT 雙權限：給 Pub/Sub service account 對 DLT topic 的 publisher role、跟對原 subscription 的 subscriber role
2. 遷移後做毒訊息演練：故意 publish 一筆會失敗的訊息、確認它真的在 max attempt 後進 DLT、不是卡在原 subscription
3. 監控 DLT backlog：DLT 開一個 subscription 監控其 num_undelivered_messages、確認毒訊息有被導流且有人處理、對照 Mercari DLT 案例的設計

漸進 cutover：dual publish 加雙消費對帳

跨雲遷移風險高、不適合一次切換、走漸進 cutover 把可逆邊界拉長：

1. Phase 0：拓樸盤點 — 列出所有 SQS queue、標記哪些是單一 queue、哪些是 SNS fan-out、各自映射到 Pub/Sub 的 topic / subscription 結構
2. Phase 1：Pub/Sub 端建好對位資源 — 建 topic / subscription / DLT、配齊 IAM 與 service account、重建 Cloud Monitoring 告警、application 寫好 Pub/Sub consumer 但先不收流量
3. Phase 2：dual publish — producer 同時 publish 到 SQS 跟 Pub/Sub、兩邊 consumer 都跑、Pub/Sub 端的處理結果先寫到隔離區或標記、不影響正式下游
4. Phase 3：雙消費對帳 — 抽樣比對兩邊處理的訊息 ID 與數量、確認 Pub/Sub 端沒漏、沒重複到無法接受的程度、ack deadline / fan-out / ordering 行為都符合預期
5. Phase 4：流量切換 — 對帳通過後、把正式下游切到 Pub/Sub 端、SQS 端轉成備援、保留一段觀察期可回切
6. Phase 5：下線 SQS — 觀察期穩定後停掉 dual publish、移除 SQS 資源、消除穩態跨雲 egress（這是不可逆階段、不要在對帳沒過時提前做）

對帳期是這套流程的核心保險、也是 Case 4 跨雲成本的來源 — 對帳用抽樣、並行窗口設明確截止日、平衡「驗證信心」跟「雙雲成本」。

Capacity / cost 對照

判讀：穩態成本兩者量級相近、真正的成本差在 遷移期 — dual publish 雙雲並行加跨雲對帳搬運是一次性高峰、不是穩態。把這段窗口縮短、是控制跨雲遷移成本的關鍵、不是去比 SQS 跟 Pub/Sub 的單價。扇出重度的系統遷到 Pub/Sub 後、少掉 SNS 那一層、扇出的計費結構也變簡單。

整合 / 下一步

遷移後事件可直接落 GCP 資料平台

遷到 Pub/Sub 的一個結構性好處、是事件可以用 BigQuery subscription 直接寫進 BigQuery、不需要再寫 Dataflow pipeline 搬運；或用 Cloud Storage subscription 批次落 GCS。這正是「workload 重心在 GCP」這條 driver 的回報 — 事件層跟資料平台同雲、省掉跨雲搬運。這也是評估是否該跨雲遷移時、要放進 ROI 的一邊。

跟 Kafka 遷移的結構對照

結論：SQS → Pub/Sub 不是 paradigm shift（兩端都是 cloud-managed 訊息服務、可收斂成單一目標）、是 operational redesign 為主、消費抽象重設計為輔的跨雲遷移；結構由主導差異維度（operational）決定主軸、高維度（components / topology）抽獨立段補充。

相關連結

• Source / target vendor：AWS SQS / Google Pub/Sub
• 平行 vendor：Kafka / RabbitMQ / NATS
• 平行 migration playbook：Kafka ↔ NATS
• 引用案例：3.C64 Mercari Item Feed DLT / 3.C61 Spotify autoscaling
• Methodology：Migration Playbook 寫作方法論
• 上游概念：0.3 非同步選型 / 6.12 idempotency / replay

本文是 AWS SQS overview 的 implementation-layer deep article。本文的 CLI 指令語法經 LocalStack round-trip 驗證、真實 AWS 的 scaling 行為、Lambda event source mapping 細節與計費數字依 AWS 官方文件。

SQS 沒有 broker ACK，delivery 控制全靠 visibility timeout

SQS 跟自管 broker（RabbitMQ / Kafka）最大的操作差異是：consumer 不會跟 broker 維持一條長連線、也沒有 channel-level 的 ack / nack 協議。SQS 的整個 delivery 保證建立在一個計時器上 — visibility timeout。訊息被 ReceiveMessage 拉走後進入 in-flight 狀態、在 timeout 視窗內對其他 consumer 不可見；consumer 處理成功就呼叫 DeleteMessage 把它移除、處理失敗或當機則什麼都不做、等 timeout 到期訊息自動回到 queue 重新可見。

這個設計把「確認處理完成」的責任從 broker 連線狀態轉移到 consumer 的主動刪除。好處是 consumer 可以隨時死掉、重啟、水平擴縮、不需要維持任何 session 狀態 — 訊息不會因為連線斷掉而遺失。代價是 visibility timeout 這個數字變成最容易設錯、後果最隱蔽的參數：設太短訊息會在 consumer 還在處理時就重新可見、被另一個 consumer 重複領走；設太長則 consumer 當機後訊息要等很久才回到 queue、retry 延遲拉長。

實機建立一個 queue 並查 default、可以確認這個視窗的起點。新建 queue 的 VisibilityTimeout 預設 30 秒：

1# 不帶任何 attribute 建 queue
2aws sqs create-queue --queue-name demo-default
3
4# 查 default visibility timeout
5aws sqs get-queue-attributes \
6  --queue-url <url> \
7  --attribute-names VisibilityTimeout
8# => "VisibilityTimeout": "30"

30 秒對「處理時間穩定在數百毫秒」的 task 綽綽有餘、對「呼叫第三方 API、跑批次轉檔、寫多個下游」的 task 則經常不夠。下一節先把這個參數設對，後面的故障演練再展開它設錯時的具體徵兆。

對齊 visibility timeout 與 consumer 處理時間

設定 visibility timeout 的判準是「略高於 consumer 處理單則訊息的最大時間」、不是平均時間。Capital One 的官方 tech blog 在講 SQS + Lambda 時明示這條原則：visibility timeout 應比最大處理時間略高 — 因為決定 redelivery 的是尾端那幾則最慢的訊息、不是中位數。處理時間 p50 是 2 秒、p99 是 25 秒時、visibility timeout 要對齊 p99 加緩衝、設到 30-40 秒、而不是看 p50 設 10 秒。

建 queue 時直接帶 VisibilityTimeout attribute，或對既有 queue 用 set-queue-attributes 調整：

1# 建立時指定（單位：秒；上限 12 小時 = 43200）
2aws sqs create-queue \
3  --queue-name demo \
4  --attributes VisibilityTimeout=60
5
6# 對既有 queue 調整
7aws sqs set-queue-attributes \
8  --queue-url <url> \
9  --attributes VisibilityTimeout=120

處理時間本身不可預測的場景（例如轉檔大小差異大、下游 API 偶發慢）、用一個固定的 queue-level visibility timeout 會兩頭不討好：對齊最壞情況會讓正常訊息當機後 retry 太慢、對齊正常情況會讓慢訊息 redelivery。SQS 給的工具是 ChangeMessageVisibility — consumer 在處理過程中發現這則會花更久時，主動延長這一則訊息的 visibility timeout，而不影響 queue default：

1# consumer 拿到 ReceiptHandle 後，動態把這則延長到 120 秒
2aws sqs change-message-visibility \
3  --queue-url <url> \
4  --receipt-handle <receipt-handle> \
5  --visibility-timeout 120

實務上長任務 consumer 的常見寫法是「heartbeat extension」：每處理一段就呼叫一次 ChangeMessageVisibility 往後推、形成一個續命迴圈、直到處理完成才 DeleteMessage。這把「我還活著、還在處理這則」的訊號明確化、避免用一個保守的 queue-level 大數字一刀切。ReceiptHandle 是每次 ReceiveMessage 回傳的一次性 token、不是 message id — 同一則訊息被重新領取後 ReceiptHandle 會變、延長操作必須用當次領取拿到的那一個。

Long polling 決定空輪詢成本，short polling 是預設陷阱

Polling 模式直接決定 SQS 的 request 帳單，因為 SQS 按 request 數計費、而 ReceiveMessage 即使沒拿到訊息也算一次 request。Short polling（預設、WaitTimeSeconds=0）的行為是「立即回應」：consumer 發 ReceiveMessage、SQS 抽樣一部分 server 立刻回、queue 空的時候回一個空 response。Consumer 為了即時拿到訊息會緊接著再發一次、形成高頻空輪詢 — 在低流量 queue 上、絕大多數 request 都是空回、帳單全花在「問有沒有訊息」上。

Long polling（WaitTimeSeconds 設 1-20 秒）改變這個行為：SQS 收到 ReceiveMessage 後、若 queue 當下沒訊息、會 hold 住這條連線最多 WaitTimeSeconds 秒、期間一有訊息到達就立刻回傳、整段時間都沒訊息才回空。對 consumer 端來說一個 20 秒的 long poll 取代了 20 秒內可能發出的數十次 short poll、空 request 數量大幅下降。

1# long polling：等到有訊息或最多 20 秒才回
2aws sqs receive-message \
3  --queue-url <url> \
4  --wait-time-seconds 20

設定 long polling 有兩個位置：per-request 帶 --wait-time-seconds、或 queue-level 設 ReceiveMessageWaitTimeSeconds attribute 讓所有 receive 預設走 long polling。後者更穩、不依賴每個 consumer 都記得帶參數。20 秒幾乎總是對的選擇：它把空輪詢壓到最低、而 latency 代價只在「queue 剛好空、訊息在 poll 結束後才到」這個邊界出現 — 大多數有持續流量的 queue 根本碰不到 20 秒上限。唯一要留意的是 consumer 的 socket timeout 必須大於 WaitTimeSeconds、否則 client 會在 SQS 還在 hold 連線時自己先 timeout 斷線。

SQS + Lambda：event source mapping 把 polling 交給 AWS

把 SQS 接上 Lambda 時、polling 這件事整個從應用程式碼消失、改由 Lambda 的 event source mapping 接管。Event source mapping 是 Lambda service 內部一組 managed poller、持續對 queue 做 long polling、把拉到的訊息打包成 batch 同步 invoke 函式、函式正常返回就由 service 代為 DeleteMessage。Consumer 端不再寫 receive / delete 迴圈、只寫處理單一 batch 的 handler。

這套 managed poller 的 scaling 不是線性的、有 ramp-up 上限。Capital One 觀察到的行為是：Lambda 初始開 5 個並行的 long polling 連線、隨 queue 累積每分鐘最多增加 60 個 instance、standard queue 的並行 batch 上限到 1000。這意味著 queue 突然湧入大量訊息時、Lambda 不會瞬間炸開到滿並行、而是分鐘級爬升 — 容量規劃時要把這段 ramp-up 期算進 backlog 消化時間、不能假設「訊息一到就有足夠 consumer」。

兩個核心參數決定每次 invoke 的形狀：

Batch size 拉大表面上省錢 — invoke 次數少、每則訊息分攤的 request 成本低。但它跟下一節的部分失敗處理直接耦合：batch 越大、一則毒訊息拖累整批重投的範圍越大。Batch window 則是流量稀疏時讓 batch 攢滿的手段、流量本來就密集時設不設都差不多、反而會引入不必要的 latency。

DLQ 與 redrive policy：用 maxReceiveCount 隔離毒訊息

毒訊息（永遠處理失敗的訊息 — 格式損壞、引用了已刪除的資源、觸發 consumer 確定性 bug）會在 visibility timeout 機制下無限重投：處理失敗、timeout 到期、重新可見、再次被領取、再次失敗。沒有上限的話這則訊息會永遠佔用 consumer 資源、且其他正常訊息的處理被它反覆插隊。Dead-letter queue（DLQ）加 maxReceiveCount 是 SQS 對這個問題的標準解 — 訊息被接收超過 N 次後、SQS 自動把它移到另一個指定的 queue（DLQ）、主 queue 不再被它卡住。

設定分兩步：先建一個普通 queue 當 DLQ、取它的 ARN、再對主 queue 設 redrive policy 指向這個 ARN 並設 maxReceiveCount：

 1# 1. 建 DLQ 並取得 ARN
 2aws sqs create-queue --queue-name demo-dlq
 3aws sqs get-queue-attributes \
 4  --queue-url <dlq-url> \
 5  --attribute-names QueueArn
 6# => "QueueArn": "arn:aws:sqs:us-east-1:000000000000:demo-dlq"
 7
 8# 2. 對主 queue 設 redrive policy（被接收 5 次後送 DLQ）
 9aws sqs set-queue-attributes \
10  --queue-url <main-url> \
11  --attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:000000000000:demo-dlq\",\"maxReceiveCount\":\"5\"}"}'

DLQ 不是訊息的墳場、是待診斷的暫存區。對應 poison message quarantine 的思路、DLQ 累積要分兩種根因處理：訊息格式錯（永遠失敗、需要修 producer 或人工丟棄）vs 下游服務暫時 down（訊息本身沒問題、修好下游後可以重放）。後者用 redrive 把訊息從 DLQ 批次放回主 queue 重新處理、對應 dlq drain 的排空流程。判斷之前先看 DLQ 裡訊息的內容、不要不加判斷地 redrive — 把毒訊息 redrive 回去只會再走一輪 maxReceiveCount 又回到 DLQ。

maxReceiveCount 設多少是取捨：太小（例如 1-2）會讓「下游短暫抖動」這種暫時性失敗被誤判成毒訊息、過早送進 DLQ；太大（例如 100）會讓真正的毒訊息浪費大量 consumer 重試。多數 task queue 設 3-5 是合理起點 — 足以吸收幾次暫時性失敗、又不至於讓確定性失敗的訊息空轉太久。

Message size 限制與 extended client

SQS 單則訊息上限是 256 KB（含 message body 與 attributes）。這對純事件通知、id 引用、小型 payload 足夠、但對「訊息本身要攜帶大檔案內容」的場景不夠 — 例如要傳一份報表、一張圖、一段長文字。直接的反模式是把大內容塞進 message body、撞上 256 KB 限制後 SendMessage 直接報錯。

標準解是 claim-check 模式：大 payload 寫到 S3、訊息只攜帶 S3 的物件引用（bucket + key）、consumer 收到訊息後再去 S3 取內容。AWS 提供的 Extended Client Library（Java / Python 等 SDK）把這個模式封裝起來 — SendMessage 時若 payload 超過門檻、library 自動把內容寫 S3、訊息只帶 pointer；consumer 端 ReceiveMessage 時 library 自動從 S3 取回、對應用程式碼透明。

選擇門檻時要把 S3 的 request 成本與 latency 算進來：每則大訊息變成「一次 S3 PUT + 一次 SQS Send」、consumer 端「一次 SQS Receive + 一次 S3 GET」。對大多數 payload 都超過 256 KB 的 queue、這是必要成本；對 payload 多數很小、偶爾爆量的 queue、extended client 只在超門檻時走 S3、混合成本可接受。Payload 普遍很大且高頻的場景、要重新評估 SQS 是否適合 — 可能該改用 streaming（Kinesis / Kafka）或乾脆讓 producer / consumer 直接交換 S3 引用、SQS 只傳通知。

Cost：按 request 計費，每一次操作都是一個 request

SQS 的計費模型是 per-request、不是 per-message-stored、也沒有固定月費。每一次 API call — SendMessage、ReceiveMessage（含空回）、DeleteMessage、ChangeMessageVisibility — 都算一個 request。這個模型對成本估算的影響是：帳單由「操作次數」驅動、而非「訊息量」或「儲存時長」。一則訊息從 producer 到 consumer 的最小生命週期是 send（1）+ receive（1）+ delete（1）= 3 個 request；空輪詢、retry、visibility 延長都會額外加 request。

兩個降低 request 數的主要手段：

第一是 batch 操作。SendMessageBatch 與 DeleteMessageBatch 一次最多打包 10 則、而 SQS 把一個 batch call 算作一個 request（實際計費以 64 KB 為一個 request 單位、一個 batch 在此範圍內仍是少數 request）。把 10 則訊息的 send 從 10 個 request 壓成 1 個 batch request、在高頻 queue 上是數量級的成本差異：

1aws sqs send-message-batch \
2  --queue-url <url> \
3  --entries 'Id=m1,MessageBody=a' 'Id=m2,MessageBody=b'

第二是 long polling 消滅空 request — 前面 polling 段已經展開。低流量 queue 的帳單若異常高、第一個要查的就是有沒有開 long polling、consumer 是不是在 short polling 下高頻空轉。

Data transfer cost 只在跨 region 時出現 — 同 region 內 producer / consumer 與 SQS 之間的傳輸不計流量費。把 producer、consumer、queue 放在同一個 region 是預設、跨 region 設計要把 egress 成本明確算進來。FIFO queue 的 per-request 單價比 standard 高、是用成本換 ordering 與去重保證 — 不需要嚴格順序的場景用 standard、把這筆溢價省下來。

Rapid7 的規模參考點說明這個計費模型在極端規模下的份量：Rapid7 公開引述 SQS 撐住「每天數十億則訊息」。在這個量級、per-request 計費乘以訊息數是一筆需要認真建模的成本 — batch、long polling、避免不必要的 visibility 延長、控制 retry 次數、每一項節省都被訊息量放大。SQS 在數十億級可用、但成本結構必須被當作架構參數對待、不是事後才看帳單。

Production 故障演練

故障一：visibility timeout 短於處理時間，訊息被重複處理

徵兆：consumer log 顯示同一個 message id 在短時間內被處理多次、下游出現重複的副作用（重複扣款、重複寄信、重複寫入）；CloudWatch 的 ApproximateNumberOfMessagesNotVisible（in-flight 數）異常高、NumberOfMessagesReceived 遠大於 NumberOfMessagesDeleted。

根因：visibility timeout 設定值低於 consumer 實際處理單則訊息的時間。訊息在 consumer 還沒處理完、還沒呼叫 DeleteMessage 之前、timeout 就到期、訊息重新可見、被另一個 consumer（或同一個 consumer 的下一輪 poll）領走。新建 queue 的 default 是 30 秒 — 處理時間長於此就會踩到：

1aws sqs get-queue-attributes \
2  --queue-url <url> \
3  --attribute-names VisibilityTimeout
4# 看到 30 而 consumer 處理時間 > 30s，就是這個問題

修法：把 visibility timeout 對齊 consumer 處理時間的 p99 加緩衝、用 set-queue-attributes 調高；處理時間變異大的長任務改用 ChangeMessageVisibility heartbeat 在處理中動態延長。同時、因為 SQS standard 是 at-least-once、重複投遞在故障與 retry 下本來就會發生、consumer 的處理邏輯必須冪等 — 對齊 visibility timeout 降低重複頻率、冪等性才是真正消除重複副作用的防線。

故障二：short polling 預設導致低流量 queue 帳單異常

徵兆：一個訊息量很低的 queue、月度 SQS 帳單卻很高；CloudWatch 顯示 NumberOfEmptyReceives 佔 ReceiveMessage 總數的絕大比例 — 大量 request 是空回。

根因：consumer 走 short polling（WaitTimeSeconds=0、預設值）、在 queue 空的時候緊密地反覆發 ReceiveMessage、每次都立即空回、每次都計一個 request。流量越低、空回比例越高、帳單越是花在「問有沒有訊息」上。

修法：在 queue-level 設 ReceiveMessageWaitTimeSeconds=20 讓所有 receive 預設走 long polling、或在每個 ReceiveMessage 帶 --wait-time-seconds 20。Queue-level 設定更穩、不依賴每個 consumer 記得帶參數。設定後 consumer 在 queue 空時會 hold 住連線最多 20 秒、空 request 數量級下降、帳單同步下降。同時確認 consumer 的 socket timeout 大於 20 秒、避免 client 先於 SQS 斷線。

故障三：Lambda batch 部分失敗，整批訊息被重投

徵兆：一個 batch 裡只有少數訊息處理失敗、但整批訊息（含已成功的）全部回到 queue 重新處理；下游對已成功的訊息出現重複副作用；DLQ 累積速度遠超實際毒訊息數量。

根因：Lambda event source mapping 的 default 行為是「整批成敗一體」— 函式只要拋出錯誤、整個 batch 被視為失敗、所有訊息（包含已經處理成功的）都不會被刪除、全部重新可見重投。Batch size 越大、一則失敗拖累的成功訊息越多。

修法：啟用 partial batch response — event source mapping 設 ReportBatchItemFailures、handler 返回時只回報失敗的 message id 清單、SQS 只把這些重投、已成功的正常刪除。這把失敗的爆炸半徑從「整批」縮到「真正失敗的那幾則」。配合縮小 batch size 進一步降低單批風險、並確保 handler 冪等以承受不可避免的重投。Handler 必須正確實作 partial response 的返回格式 — 漏回報某則失敗會讓它被當成成功刪除、訊息靜默遺失。

故障四：maxReceiveCount 設定不當，毒訊息空轉或誤判

徵兆：兩種相反的故障形狀。一是 DLQ 幾乎為空但主 queue 有訊息反覆重試數十次、consumer log 同一 message id 重複出現、佔用處理容量 — maxReceiveCount 設太大。二是 DLQ 快速累積大量其實沒問題的訊息、redrive 回去又能正常處理 — maxReceiveCount 設太小、把下游短暫抖動誤判成毒訊息。

根因：redrive policy 沒設、或 maxReceiveCount 與「暫時性失敗的正常重試次數」不匹配。沒設 redrive policy 時毒訊息無限重投；設太大時毒訊息空轉太久才進 DLQ；設太小時正常訊息在下游抖動期間被過早判死。

修法：對主 queue 設 redrive policy、maxReceiveCount 取 3-5 作為起點 — 足以吸收幾次暫時性失敗、又不讓確定性失敗的訊息空轉太久。觀察 DLQ 的累積模式再微調：DLQ 累積的多是「下游修好後 redrive 能成功」的訊息就調高、累積的多是「redrive 回去又進 DLQ」的真毒訊息就維持或調低。對 DLQ 設 CloudWatch alarm 監控 ApproximateNumberOfMessagesVisible、累積超過閾值就告警人工介入、區分 redrive vs 丟棄。

故障五：FIFO queue 撞上吞吐上限

徵兆：把 standard queue 換成 FIFO 取得 ordering 後、高峰流量下 producer 端開始收到 throttling、訊息積壓、SendMessage 報限流錯誤；吞吐怎麼加 consumer 都上不去。

根因：FIFO queue 為了維持順序與去重、吞吐遠低於 standard。FIFO 的基礎吞吐是每秒 300 則訊息（API call）、開啟 batching 後到每秒 3000 則。更關鍵的是順序保證的粒度在 MessageGroupId — 同一個 group 內的訊息嚴格串行處理、跨 group 才能並行。若所有訊息共用一個 group id、實際並行度退化成 1、無論加多少 consumer 都無法並行消化。

1# FIFO send 必須帶 MessageGroupId（決定順序與並行粒度）
2aws sqs send-message \
3  --queue-url <fifo-url> \
4  --message-body "ordered-1" \
5  --message-group-id "group-a"

修法：先確認是否真的需要全域順序 — 多數場景只需要「同一個實體（同一用戶、同一訂單）內部有序」、不需要跨實體有序。把 MessageGroupId 設成業務實體 id（用戶 id、訂單 id）、讓不同實體的訊息能跨 group 並行、吞吐隨 group 數量擴展。確定需要嚴格全域順序且吞吐撞頂的場景、FIFO 的設計上限就是天花板 — 此時要重新評估是否該換成 streaming（Kafka 的 partition 模型在 per-key 有序下提供更高並行）、或拆分 queue。不需要任何順序保證的場景、退回 standard queue、把 FIFO 的吞吐限制與成本溢價一起省掉。

整合與下一步

跟 consumer 設計能力對接

本文的 visibility timeout heartbeat、partial batch response、冪等處理都是 3.4 consumer 設計 的具體落地 — consumer-design 講語言無關的 consumer 模式、本文是 SQS 上的實作形狀。retry 與 replay 的交接路徑見 queue consumer retry replay handoff。

跟知識卡對位

DLQ 段對應 poison message quarantine（毒訊息隔離）與 dlq drain（DLQ 排空）兩張卡 — SQS 的 redrive policy + maxReceiveCount 是這兩個概念在 managed queue 上的具體機制。visibility timeout 的 in-flight 概念見 in-flight。

跟 case 對位

visibility timeout 與 Lambda event source 的 ramp-up 行為來自 3.C50 Capital One；at-least-once + DLQ 在工作排程的取捨來自 3.C48 Airbnb Dynein；per-request cost 在極端規模的份量來自 3.C59 Rapid7。

何時 revisit

FIFO 吞吐撞頂、需要 replay / streaming、或 cost 在 streaming 模型下更划算時、回 SQS overview 的「何時改走其他服務」 重新選型。跨雲 managed queue 的對照見 Google Pub/Sub。

本文是跨 vendor migration playbook、cross-link 到 RabbitMQ 跟 AWS SQS。對照 Kafka ↔ NATS 的 paradigm shift、本篇主導差異維度是 operational model：source 跟 target 都是任務隊列、能力大致對得上、但運維責任從「自管 broker 叢集」整批交給 AWS managed 服務。

RabbitMQ → AWS SQS 的核心是把 broker 運維責任轉移給 managed 服務、同時接受 SQS 沒有 exchange routing 這個事實、把路由邏輯收斂回 application 或改用 SNS fan-out。這個遷移不是 protocol drop-in（AMQP client 不能直接連 SQS）、application 端需要改 delivery 控制機制（manual ack → visibility timeout + delete）；但它也不是 paradigm shift（兩端都是 at-least-once 任務隊列、DLQ / 重試 / 解耦的語意一致）。主導差異落在 operational 維度、所以本文走 Type C operational redesign hybrid 結構。

為什麼遷：不想再養 RabbitMQ 叢集

觸發評估 SQS 的最常見壓力是 broker 維運成本、不是功能缺口。自管 RabbitMQ 叢集要承擔的運維責任包含 Erlang cluster 拓樸維護、network partition（腦裂）處理、quorum queue 的 Raft 一致性調校、disk / memory alarm 的容量規劃、版本升級的 rolling restart。這些責任需要至少 0.5-1 FTE 的持續投入、且在 network partition 這類事故發生時需要熟悉 Erlang runtime 的人即時介入。

SQS 把這整層責任移除。沒有 broker 實例、沒有 cluster 拓樸、沒有 disk / memory watermark、沒有版本升級。換來的代價是 routing 能力消失（SQS 沒有 exchange）、application 要改 delivery 控制機制、以及 AWS 生態綁定。這個交換在三種情境下成立：

第一種是 AWS 生態原生服務。若 producer / consumer 已經跑在 Lambda、ECS、EKS 上、SQS 的 event source mapping 跟 IAM 整合讓 application 不必自管連線池跟認證。RabbitMQ 在 AWS 上要嘛自管 EC2 叢集、要嘛用 Amazon MQ（仍是 broker 模型、運維責任只是部分轉移）、都不如 SQS 的 serverless 整合直接。

第二種是 routing 邏輯本來就簡單。若 RabbitMQ 的用法是 direct exchange + 少數固定 routing key、或單純 worker pool 消費單一 queue、那 exchange 的靈活性本來就沒被用到、遷到 SQS 不損失能力。Airbnb 的 Dynein 分散式延遲任務系統就是這個形狀：用 SQS at-least-once + DLQ 取代原本受限於單 Redis 的 Resque、每 scheduler instance 達約 1000 QPS、水平擴展（見 3.C48 Airbnb Dynein）。任務排程對「不丟資料」的需求 at-least-once 足夠、不需要 broker 級 routing。

第三種是團隊規模不支撐 broker 專業。小團隊養一套 RabbitMQ 叢集、真正用到的是「可靠的任務隊列 + DLQ」、但要付出整套 Erlang 運維學習曲線。把這層交給 SQS、團隊把精力放回 application 邏輯。

6 維 diff dimension audit

遷移前先跑 diff dimension audit、對每個維度評估 source 跟 target 的差異程度、決定主導維度跟結構：

主導維度是 operational（高）：遷移的核心價值跟核心風險都在「broker 運維責任整批轉移」。Application change 維度評中高、因為 delivery 控制機制要改、但這是受控的 SDK 層改寫、不是 paradigm 重設計。Components 維度評中、因為 exchange routing 在 SQS 沒有對等物、要靠 SNS fan-out 或多 queue 補回來。其餘三維度低或中。

主導維度落在 operational、所以主結構走 Type C：以 operational redesign 對位開頭、phased 執行、故障演練聚焦在「以為對等其實不對等」的運維陷阱。Application change 跟 Components 兩個次高維度不硬塞進主結構、各自抽出獨立段（下面「application 改寫」跟「routing 收斂」兩段）。

Operational redesign 對位

Operational 維度差異最大、先逐項對位「原本自己做的事、現在誰做、怎麼做」：

前四列是純收益：責任消失、不需要對等實作。後三列是責任轉移、不是消失 — delivery 控制從 broker 移到 client、重試從 DLX 移到 redrive policy、routing 從 broker 移到 application。這三列正是故障演練聚焦的地方、因為「以為功能還在、其實機制換了」是這類遷移的主要事故來源。

監控這列值得展開。RabbitMQ 的 queue depth、unacked、consumer 數量是從 broker 直接讀；SQS 改看 CloudWatch 的 ApproximateNumberOfMessagesVisible（queue depth）跟 ApproximateAgeOfOldestMessage（lag 訊號）。差異在於 SQS 的 metric 是 approximate、且有分鐘級延遲、不適合用來做秒級的 backpressure 決策。原本靠 RabbitMQ Management UI 即時看 queue 狀態的 runbook 要改寫成 CloudWatch alarm 驅動。

Application 改寫：manual ack → visibility timeout + delete

Application change 維度的核心是 delivery 控制機制換了一套模型。RabbitMQ 是 broker-side 維護訊息狀態、consumer 用 ack/nack 回報處理結果；SQS 是 client-side 用 visibility timeout + 顯式 delete、broker 不維護「處理中」以外的狀態。

 1# RabbitMQ 端：manual ack pattern
 2channel.basic_qos(prefetch_count=10)  # 一次最多領 10 條未 ack
 3
 4def callback(ch, method, properties, body):
 5    try:
 6        process(body)
 7        ch.basic_ack(delivery_tag=method.delivery_tag)
 8    except Exception:
 9        # nack + requeue，或丟 DLX
10        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)
11
12channel.basic_consume(queue="orders", on_message_callback=callback)
13channel.start_consuming()

 1# SQS 端：visibility timeout + delete pattern
 2while True:
 3    resp = sqs.receive_message(
 4        QueueUrl=queue_url,
 5        MaxNumberOfMessages=10,        # batch、對應 prefetch
 6        WaitTimeSeconds=20,            # long polling
 7        VisibilityTimeout=60,          # 處理中對其他 consumer 隱藏
 8    )
 9    for msg in resp.get("Messages", []):
10        try:
11            process(msg["Body"])
12            sqs.delete_message(           # 顯式 delete = ack
13                QueueUrl=queue_url,
14                ReceiptHandle=msg["ReceiptHandle"],
15            )
16        except Exception:
17            pass  # 不 delete、visibility timeout 後自動回 queue 重試

對應關係：

• RabbitMQ basic_ack → SQS delete_message：處理成功的訊息要顯式刪除、否則 visibility timeout 後重新可見。「不做事」在 SQS 等於「重試」、在 RabbitMQ 等於「卡住 unacked」。
• RabbitMQ prefetch_count → SQS MaxNumberOfMessages（上限 10）+ visibility timeout：併發控制從「broker 限制未 ack 數量」變成「一次 receive 的 batch 大小 + 隱藏時間窗」。
• RabbitMQ basic_nack(requeue=False)（丟 DLX）→ SQS redrive policy：失敗不再是 application 主動丟 DLX、而是「達到 maxReceiveCount 次數後 SQS 自動送 DLQ」。
• RabbitMQ push 模型（broker 主動推給 consumer）→ SQS pull 模型（consumer 主動 long polling）：consumer loop 結構不同、SQS 沒有 broker 主動推送、要嘛自己 poll、要嘛交給 Lambda event source mapping 代 poll。

application 邏輯改動集中在 consumer 的 receive / ack / 重試三段、producer 端從 basic_publish 改成 send_message 相對單純。整體改動量取決於原本用了多少 AMQP 特性、典型情境是 consumer 端 20-40% 改寫。

Routing 收斂：exchange 沒了、靠 SNS fan-out 或多 queue

Components 維度的核心是 SQS 沒有 exchange、RabbitMQ 的 routing 能力要在 broker 外重建。RabbitMQ 的 exchange 在 broker 內承擔分流：一條訊息經 routing key 跟 binding 決定進哪些 queue。SQS 是裸 queue、producer 直接指定 queue、沒有中間分流層。

判讀：

• Direct exchange + 少數固定 key：最容易遷。routing 邏輯本來就是「key X 進 queue X」、改成 producer 直接 send_message 到對應 queue url。routing 從 broker 收斂進 application、程式碼多幾行 if/else 或 map 查表。
• Fanout（一條訊息給多個 downstream）：用 SNS-to-SQS。SNS topic 當 fan-out 點、每個 downstream 訂閱一個自己的 SQS queue。Twitch EventSub 就是這個形狀（見 3.C54 Twitch EventSub）：SNS fan-out 到多個 SQS、各 consumer 獨立消費。這比 RabbitMQ fanout exchange 多一層 SNS、但換來 managed 運維。
• Topic exchange（複雜層級匹配）：SNS 的 subscription filter policy 能做 attribute-based 過濾、但表達力不如 AMQP topic 的 * / # 通配。複雜 topic routing 是「不該遷」的訊號（見下節）。

關鍵取捨：SQS + SNS 把 RabbitMQ 的單一 broker（routing 內建）拆成兩個 managed 服務（SQS 排隊 + SNS 分流）。好處是各自 managed、壞處是 routing 從宣告式 binding 變成要管 SNS topic + subscription + filter policy 的組合、跨服務除錯多一層。

什麼不該遷：保留 RabbitMQ 的訊號

SQS 的 managed 簡潔有代價、三類用法遷過去會損失能力或增加複雜度：

複雜 topic routing。若 RabbitMQ 重度使用 topic exchange 的 * / # 層級通配、binding 規則數十條、那 routing 的表達力是核心價值。SNS subscription filter 的 attribute 匹配做不到對等表達、勉強遷會把 broker 內的宣告式 routing 拆成散落在 SNS filter policy + application 程式碼的命令式邏輯、維護成本反而上升。GoCardless 用單一 topic exchange 當服務 mesh（見 3.C26 GoCardless Hutch）這類設計、routing 就是架構本身、不該拆。

需要 broker 級 ordering。RabbitMQ 單 queue 預設 FIFO、consistent hash exchange 還能做 per-key ordering（見 3.C28 WeWork hash ordering）。SQS standard queue 無 ordering；要 ordering 只能用 FIFO queue、而 FIFO 吞吐受限（每 MessageGroupId 有序、整體 3000 msg/sec with batching）。若 workload 同時要高吞吐跟嚴格 ordering、SQS FIFO 兩者不可兼得、RabbitMQ 反而更適合。

RPC over messaging（request-reply）。RabbitMQ 的 reply-to + correlation-id 做同步 RPC 模式、SQS 沒有原生 request-reply、要自己用兩條 queue + correlation 拼、延遲也不適合（SQS 是 task queue 不是低延遲傳輸）。這類用法該考慮 NATS 的 request-reply 或直接 HTTP。

Migration 結構：漸進 cutover

operational redesign 的 cutover 走 dual-run、按 queue（不是按整個叢集）漸進切、每步都保留回退邊界：

1. Phase 0：scope 盤點 — 列出所有 exchange / queue / binding、標註 routing 模式（direct / fanout / topic）跟 ordering 需求。判斷哪些 queue 適合遷（簡單 routing、at-least-once 夠用）、哪些保留（複雜 topic、需 broker ordering、RPC）。
2. Phase 1：SQS / SNS 基礎建設 — 對適合遷的 queue 建對應 SQS queue + DLQ（設 redrive policy + maxReceiveCount）、fanout 場景建 SNS topic + subscription。設好 IAM policy、visibility timeout 對齊 consumer 最大處理時間。
3. Phase 2：consumer 改寫 + dual-consume — application consumer 改成 SQS pull 模型（或 Lambda event source）、先讓新 consumer 跟舊 RabbitMQ consumer 並存、producer 暫時雙寫到 RabbitMQ + SQS、驗證 SQS 端處理正確。
4. Phase 3：producer cutover — 逐 queue 把 producer 從 RabbitMQ 切到 SQS / SNS、停掉該 queue 的雙寫。這步可逆：發現問題切回 RabbitMQ producer 即可。
5. Phase 4：下線 RabbitMQ queue — 確認某 queue 在 SQS 穩定運行、且 RabbitMQ 端該 queue 已排空、才停掉 RabbitMQ 對應的 exchange / queue。這是不可逆步驟、不該過早。
6. Phase 5：叢集退役 — 所有適合遷的 queue 都切完、RabbitMQ 只剩保留的複雜 routing queue（或完全清空）、才縮編或退役叢集。

漸進 cutover 的關鍵是 按 queue 切、不按叢集切。每條 queue 是獨立的遷移單元、各自走 Phase 2-4、互不阻塞。複雜 routing 的 queue 可以永遠留在 RabbitMQ、形成 RabbitMQ + SQS 長期共存的混合架構。

Production 故障演練

Case 1：DLX 改 redrive policy，重試語意不對等

徵兆：RabbitMQ 端用 DLX 配 message TTL 做「延遲重試 + 多層 escalation」（如 3.C25 Indeed Delay + DLQ 的三層 retry）；遷到 SQS 後發現 redrive policy 只能設「失敗 N 次直接進 DLQ」、做不出原本的延遲重試階梯。

根因：RabbitMQ DLX 是 routing 機制、能配 TTL + 多個中繼 queue 組出任意 escalation 拓樸；SQS redrive policy 是單一規則（maxReceiveCount 到了就送 DLQ）、沒有中繼層。兩者都叫「DLQ」、但 RabbitMQ 的是可編程 routing、SQS 的是固定計數。

修法：

1. 指數退避用 visibility timeout 做：失敗時 application 主動 ChangeMessageVisibility 延長隱藏時間、實現退避、而不是依賴 DLX TTL。
2. 多層 escalation 用多 queue 串：若真需要 N 層、建 N 個 SQS queue、application 失敗時把訊息 send 到下一層 queue、每層設不同 redrive policy。複雜度比 DLX 高、是「複雜 routing 不該遷」的訊號之一。
3. 接受簡化：多數 task queue 的重試需求是「重試幾次後進 DLQ 人工檢視」、SQS redrive policy 直接對應、不需要重建 escalation 階梯。

Case 2：prefetch 改 batch + visibility，併發控制行為變了

徵兆：RabbitMQ 端 prefetch_count=1 確保 worker 一次只處理一條（公平派發、慢任務不囤積）；遷 SQS 後 consumer 一次 receive_message 領 10 條、其中一條慢任務拖累整批、且 visibility timeout 對整批同時計時、處理到一半超時導致前面已處理的訊息重複。

根因：RabbitMQ prefetch 是 per-message 的未 ack 上限、broker 逐條控制；SQS 的 batch 是一次領多條、visibility timeout 對 batch 內每條獨立計時、但 application 若同步處理整批、慢的那條會讓後面的訊息在處理前就接近超時。

修法：

1. 慢任務用 batch size 1：對等 RabbitMQ prefetch=1 就設 MaxNumberOfMessages=1、一次領一條、避免批內互相拖累。
2. visibility timeout 設成略高於最大處理時間：Capital One 的 SQS + Lambda 實務明示這點（見 3.C50 Capital One）— timeout 太短重複處理、太長延遲 retry。長任務處理中主動 ChangeMessageVisibility 續期。
3. 逐條 delete 不等整批：每條處理完立刻 delete_message、不要等整批做完才一起刪、降低整批超時導致部分重複的風險。

Case 3：fanout 改 SNS-to-SQS，漏訂閱導致部分 downstream 收不到

徵兆：RabbitMQ fanout exchange 廣播到所有 binding queue、新增 downstream 只要 bind 上去就收得到；遷成 SNS-to-SQS 後、某個新 downstream 的 SQS queue 沒訂閱到 SNS topic、或 subscription filter policy 設錯、導致該 downstream 靜默漏訊息。

根因：RabbitMQ fanout 的廣播是 broker 內建語意、binding 一建立就生效；SNS-to-SQS 的 fan-out 是「每個 downstream 各自建 SQS queue + 訂閱 SNS topic + 設 queue policy 允許 SNS 投遞」三步、任一步漏掉或 filter policy 寫錯就靜默漏。多一層服務 = 多一層配置出錯點。

修法：

1. 訂閱關係 IaC 管理：SNS subscription + SQS queue policy 用 Terraform / CloudFormation 宣告、避免手動建漏。
2. 驗證 fan-out 完整性：cutover 前發測試訊息、確認每個 downstream queue 都收到（對照 RabbitMQ 端 binding 清單逐一核對）。
3. filter policy 預設寬鬆：除非明確要過濾、subscription 不設 filter policy（全收）、避免「以為廣播、實際被 filter 擋掉」。

Case 4：訊息超過 256KB，SQS 拒收

徵兆：RabbitMQ 對單訊息大小無硬性低上限（受 frame_max / memory 限制、實務常見 MB 級 payload）；遷 SQS 後、原本能傳的大 payload 訊息被拒、SendMessage 報 message 超過 256KB 上限。

根因：SQS 單訊息上限 256KB（含 message attribute）。RabbitMQ 沒有這個低上限、application 可能習慣直接把大 payload（如完整文件、序列化大物件）塞進訊息體。

修法：

1. Claim-check pattern：大 payload 存 S3、訊息只放 S3 物件的引用（key / presigned URL）、consumer 收到後從 S3 取。FINRA 的大檔案處理是 S3 event notification → SQS（檔案上傳 S3 後由 S3 推通知），結果同樣讓訊息只帶 S3 物件引用，但機制是 S3 觸發、不是 producer 主動 offload（見 3.C53 FINRA Large File）。
2. SQS Extended Client Library：AWS 官方 library 自動把超過上限的 payload 透明存 S3、訊息存指標、consumer 端自動取回、application 程式碼幾乎不改。
3. 盤點 payload 大小分佈：Phase 0 audit 時量測現有訊息大小、超 256KB 的比例決定是否需要 claim-check、避免 cutover 後才發現大量訊息被拒。

Case 5：ordering 從 RabbitMQ 到 SQS FIFO，吞吐撞天花板

徵兆：RabbitMQ 單 queue 提供順序消費、原本靠這個保證同一筆訂單的事件有序處理；遷 SQS standard queue 後 ordering 消失、改用 SQS FIFO queue 恢復 ordering、但吞吐從原本的數萬 msg/sec 掉到 3000 msg/sec 上限、隊列堆積。

根因：SQS standard queue 無 ordering（為了吞吐跟可用性的設計取捨）；FIFO queue 提供 per-MessageGroupId 有序 + 去重、但整體吞吐上限 3000 msg/sec（with batching）。RabbitMQ 單 queue 的有序消費吞吐遠高於此。SQS FIFO 的吞吐上限是 300 TPS（不 batch）／ 3000 TPS（batch，後者為通用 SQS FIFO 數值）。Twilio 的 webhook buffer 文件特別點出 FIFO 300 TPS 這個限制（見 3.C58 Twilio webhook）。

修法：

1. 重新審視 ordering 粒度：用 MessageGroupId 把 ordering 限縮到真正需要的範圍（如 per-訂單、per-用戶）、不同 group 平行處理、整體吞吐 = group 數 × per-group 吞吐、繞過單 queue 3000 上限。
2. 拆分 ordered 跟 unordered 流量：只有真需要 ordering 的訊息走 FIFO、其餘走 standard queue 拿高吞吐。多數 workload 只有一小部分需要嚴格 ordering。
3. ordering 是「不該遷」的硬訊號：若 workload 整體都需要高吞吐 + 嚴格 ordering、SQS FIFO 兩者不可兼得、保留 RabbitMQ 或考慮 Kafka（per-partition ordering + 高吞吐）。

Capacity / cost 對照

判讀：低到中吞吐、簡單 routing、AWS 生態的 task queue、SQS 在運維成本上顯著划算（FTE 從 0.5-1 降到約 0.1）。高吞吐 + 嚴格 ordering、或重度 exchange routing 的 workload、SQS 的 per-request 成本跟能力限制可能讓 RabbitMQ（或 Kafka）反而合適。SQS 的 cost 是用量驅動、流量大時 per-request 費用要納入評估、對照 0.6 成本取捨。

整合 / 下一步

混合架構是常見終態

多數遷移不會把 RabbitMQ 完全清空。簡單 task queue 遷 SQS、複雜 topic routing / broker ordering / RPC 留 RabbitMQ、形成長期共存：

1[簡單 task queue / fanout]              [複雜 topic routing / RPC / ordering]
2        AWS SQS / SNS                              RabbitMQ
3        │                                            │
4   Lambda / ECS consumer                    自管叢集（縮編後）

按 queue 漸進切的結果就是混合架構 — 不需要為了「遷乾淨」勉強把不適合的 queue 也搬過去。

跟 RabbitMQ → Kafka 的對照

RabbitMQ 還有另一條遷移路徑是 RabbitMQ → Kafka（work queue → event streaming）。兩條路的差異：遷 SQS 是 交出運維、能力對等簡化（仍是 task queue）；遷 Kafka 是 換 paradigm、要 replay / 高吞吐 streaming（從任務隊列變 event log）。選哪條看的是「想擺脫運維」還是「需要 streaming 能力」、不是同一個決策。

跟前面 migration playbook 的結構對照

結論：兩篇都是 message queue 跨 vendor、但主導差異維度不同 — Kafka ↔ NATS 卡在 paradigm（不同抽象層）、RabbitMQ → SQS 卡在 operational（運維責任轉移）。結構由主導維度決定、不是 universal phased playbook。

相關連結

• Source / target vendor：RabbitMQ / AWS SQS
• 平行 vendor：Google Pub/Sub / NATS
• 平行 migration playbook：Kafka ↔ NATS
• 引用案例：3.C48 Airbnb Dynein / 3.C50 Capital One / 3.C54 Twitch EventSub / 3.C58 Twilio webhook
• Methodology：Migration Playbook 寫作方法論

觀察

Airbnb 構建 Dynein 分散式延遲任務排程系統取代 Resque（受限於單 Redis 實例）。明確選 SQS、利用 at-least-once delivery、dead letter queue、individual message acknowledgment、access control 與 encryption-at-rest。每個 scheduler instance 達 ~1000 QPS、可水平擴展。

判讀

at-least-once 對工作排程「不丟資料」假設足夠、SQS wrap DynamoDB 處理 > 15 分鐘 delay、DLQ 分離「短暫失敗」與「永久毒訊息」。揭露 managed queue 在工作排程的取捨：trade ordering 換 scaling。

對應大綱

SQS 進階主題：Standard vs FIFO / DLQ 設計。

下一步路由

回 SQS vendor 頁 與 3.2 durable queue。

引用源

• Dynein: Building a Distributed Delayed Job Queueing System

觀察

Airbnb 的 Inspekt 隱私資料掃描系統用 SQS task queue 派發 scan task（每 table/object/app 一個 message）、Scanner nodes 水平 pull。“each message reappears N times back into the queue until a scanner node deletes it” 是 visibility timeout 在實戰的應用。

判讀

用 message 重現次數做 retry budget、scanner 失敗時不用自管 retry table。揭露 SQS 的「不刪除即重現」是設計、不是 bug、可以當隱式 retry 機制用。

對應大綱

SQS 進階主題：Visibility timeout + in-flight messages。

下一步路由

回 SQS vendor 頁 與 3.4 consumer 設計。

引用源

• Automating Data Protection at Scale Part 2

業務背景

Capital One 是美國大型金融機構，tech blog 公開分享了 SQS + Lambda 的 event-driven 架構實踐。金融場景的 message 處理對正確性要求極高 — 重複處理一筆交易跟遺失一筆交易的代價都是具體的金錢損失。

SQS 是 AWS 原生的 managed queue，Lambda 是 serverless compute。兩者搭配的 event source mapping 是 AWS 上最常見的 event-driven 入門架構 — 看起來簡單（SQS → Lambda 自動觸發），但 visibility timeout 跟 Lambda scaling 的互動有不少實務細節。

技術挑戰

Visibility timeout 的雙邊風險

SQS 的 visibility timeout 定義了「consumer 取走訊息後，其他 consumer 多久之後才能再看到這筆訊息」。它是 SQS 的核心容錯機制 — consumer 處理失敗（crash、timeout）時，visibility timeout 到期後訊息重新出現在 queue 裡，讓其他 consumer 接手。

Timeout 太短：consumer 還在處理中、visibility timeout 已到期、另一個 consumer 取走同一筆訊息開始處理 — 重複處理。金融場景的重複處理可能導致重複扣款或重複退款。

Timeout 太長：consumer 處理失敗、需要等很久 visibility timeout 才到期、訊息才重新出現 — retry 延遲。原本幾秒就能被其他 consumer 接手的訊息，要等 15 分鐘才 retry。

Capital One 的實務建議是 visibility timeout 設為「最大預期處理時間 + 少量緩衝」。例如：最大處理時間 30 秒 → visibility timeout 設 45 秒。

Lambda event source mapping 的 scaling 行為

Lambda 跟 SQS 的整合透過 event source mapping — Lambda 服務自動從 SQS long polling 取訊息、觸發 Lambda function。使用者不需要自己寫 polling 邏輯。

Capital One 揭露的 scaling 行為跟「Lambda 自動擴展」的直覺不同：

• 初始狀態：Lambda 啟動 5 個 long polling connection（poller）
• Scale up：每分鐘最多新增 60 個 poller instance（每個 instance 處理一批 message）
• 上限：最多 1000 個並行 batch

這意味著突發流量（queue 瞬間湧入大量訊息）的消化速度不是即時的 — Lambda 需要數分鐘才能 scale 到足夠的並行度。在這段 ramp-up 期間，queue depth 會持續增長。

Batch size 跟 visibility timeout 的互動

Lambda event source mapping 預設 batch size = 10 — 一次取 10 筆訊息、用一個 Lambda invocation 處理。如果 batch 中的某一筆處理特別慢，整個 batch 的處理時間會被拉長。

Visibility timeout 要覆蓋整個 batch 的處理時間（包含最慢的那一筆），否則 batch 還在處理中、早期取走的訊息 visibility timeout 到期、被其他 poller 重新取走 — 導致重複處理。

解法與取捨

Idempotency 作為安全網

Visibility timeout 無法完全避免重複處理（網路分區、Lambda timeout 等邊界條件）。Capital One 的做法是在 Lambda function 內實作 idempotency — 用 message ID 做去重，確保同一筆訊息被多次處理時結果相同。

Idempotency 把 visibility timeout 的精確度要求降低 — 即使偶爾重複處理，業務結果仍然正確。Visibility timeout 仍然需要合理設定（降低不必要的重複 invocation 成本），但 idempotency 是「即使設錯也不會造成業務錯誤」的安全網。

回寫教材的連結

• SQS vendor 頁：visibility timeout、in-flight limit、Lambda event source 的進階主題
• 3.6 processing recovery semantics：at-least-once 語意下的 consumer 端 idempotency
• 3.2 durable queue：visibility timeout 是 SQS 的 delivery guarantee 機制
• 3.8 queue consumer retry replay handoff：DLQ + maxReceiveCount 的 retry 升級策略

判讀徵兆

讀者在自己的系統看到以下訊號時，應該回讀本案例：

• SQS + Lambda 架構中出現訊息重複處理（CloudWatch 的 ApproximateNumberOfMessagesNotVisible 跟 NumberOfMessagesReceived 比例異常）
• Lambda function 的 timeout 跟 SQS visibility timeout 的關係沒有明確設計
• 突發流量時 queue depth 持續增長、Lambda 的 concurrent execution 沒有立刻跟上
• Batch processing 中的慢訊息拖慢整個 batch、造成 visibility timeout 到期

引用源

• Using AWS Solutions for Event-Driven Serverless Architectures

觀察

Atlassian 內部 event bus StreamHub 底層用 Kinesis、但「每個 consumer 自己準備 SQS queue 接收 event」。JiRT 即時服務透過此模式把輪詢式（~1 min）改成 event-driven（秒級）。

判讀

在 Kinesis 上面疊 SQS 讓 consumer 各自設定 retention、各自獨立 visibility timeout。揭露「stream + per-consumer queue」是 fan-out 場景的常見複合 pattern、不是 streaming vs queue 二選一。

對應大綱

SQS 進階主題：Standard vs FIFO / SQS 作為 fan-out subscriber。

下一步路由

回 SQS vendor 頁 與 Kafka vendor 頁（streaming + queue 對照）。

引用源

• Using an Event-Driven Architecture to Improve Jira Software Responsiveness

觀察

Nielsen 每日處理 25 TB / 30 billion event。架構用兩個 SQS queue：work queue（待處理工作項）+ completion queue（回報完成）。Lambda 從 DB 拉檔案、組成 work item 推進 work queue、EKS pod 拉取處理、處理完寫 completion queue。基於 queue depth 自動擴 pod。

判讀

不用直接 Lambda invoke（pod 上跑長時間 Spark workload）、queue depth 當 backlog signal driving autoscale。揭露長 workload 場景該用 pod + queue depth、不是 Lambda function。

對應大綱

SQS 進階主題：CloudWatch metric + alarm / Standard queue / 長 workload autoscaling。

下一步路由

回 SQS vendor 頁 與 3.C22 Trivago KEDA（lag-based autoscale 對照）。

引用源

• How Nielsen Uses Serverless Concepts on Amazon EKS for Big Data Spark Workloads

觀察

FINRA 金融監管機構、處理 broker-dealer 上傳大檔。Large File Service 用 S3 → SQS 通知模式：使用者上傳完 loading dock bucket、S3 推 SQS message 給 LFS、移檔後再推 “file available” SQS message 給下游。

判讀

S3 通知是 SQS 最經典 trigger、KMS + bucket policy + queue 權限的合規場景（金融業要保留稽核軌跡）。揭露金融場景的 IAM 設計不是一道權限、是多層稽核軌跡。

對應大綱

SQS 進階主題：SQS + Lambda event source / IAM + Cross-account。

下一步路由

回 SQS vendor 頁 與 7 security 模組。

引用源

• FINRA Large File Service

觀察

Twitch 內部 Event Bus 發佈 ~1660 events/sec 到 SNS。EventSub（給第三方應用訂閱 Twitch 事件）用 SQS 接收 async notification、再由 Dispatcher fan-out 給各訂閱者。

判讀

fan-out 後每個 consumer 要自己一個 queue。揭露 SNS → SQS 是 AWS 生態的 fan-out 標配、SQS 是第三方訂閱的 buffer 層、Dispatcher 是 application 級別的分發責任。

對應大綱

SQS 進階主題：Standard queue + SQS + Lambda / SNS-SQS fan-out。

下一步路由

回 SQS vendor 頁 與 3.C51 Atlassian JiRT（subscription 對照）。

引用源

• Twitch State of Engineering 2023

觀察

SmugMug 用 SQS 兩種模式：(1) backfill — script 推 DynamoDB scan-segment 指令進 SQS、Lambda 拉取做平行掃描寫 OpenSearch、(2) 鏡像查詢 — production query 推副本 SQS、Lambda replay 到 replica domain。每小時可 index > 1 billion document、不影響 production。

判讀

SQS 作為「workload generator」分散式平行化、不需協調 worker 數量。揭露 SQS 不只是「事件 queue」、也是「並行任務分散」的協調基礎。

對應大綱

SQS 進階主題：Standard queue / Long polling / SQS + Lambda event source。

下一步路由

回 SQS vendor 頁 與 3.4 consumer 設計。

引用源

• SmugMug’s Durable Search Pipelines for Amazon OpenSearch Service

觀察

PostNL（荷蘭最大物流商、每天 6.9M 信件 + 1.1M 包裹）的 Event Broker E-commerce 系統每天處理 ~10M message。完整列出 SQS 配置：每 producer/consumer 隔離 stack（最小爆炸半徑）、3 天 replay via EventBridge、exponential backoff with jitter、24 小時內最多 retry 100 次、final DLQ 允許 consumer 自己 redrive。max receive count 設 1 觸發 DLQ 告警。

判讀

「每 producer/consumer 隔離 stack」是 mission-critical 系統的 blast radius 設計、不只是 queue 配置。揭露 production-grade SQS 設計含三件事：隔離 + retry 政策 + redrive 流程。

對應大綱

SQS 進階主題：DLQ 設計 / CloudWatch alarm / Cost 模型。

下一步路由

回 SQS vendor 頁 與 3.C9 反例：語義誤配。

引用源

• Designing a Mission-Critical Serverless Application for High Resilience

觀察

Lob（programmatic mail API）原本用 bbc/sqs-consumer 但被鎖在 AWS SDK v2。他們 fork 出 @lob/sqs-consumer：支援 SDK v3（模組化 import 縮 bundle、TypeScript 一級支援、async/await）、修正原 library 對 FIFO queue 的 bug。SQS 用在 Lob API 跟其他內部 service。

判讀

不能只靠 SDK 原生 API、SDK 升級會逼出 library 維護議題。揭露「FIFO queue 跟 standard queue 的 client 行為差異」是 library 層的隱性 bug 來源。

對應大綱

SQS 進階主題：Standard vs FIFO / Long polling / Client library 維護。

下一步路由

回 SQS vendor 頁 與 3.4 consumer 設計。

引用源

• @lob/sqs-consumer

觀察

Twilio 自己 engineering blog 教使用者用 SQS 緩衝來自 Twilio 的高流量 SMS / status callback webhook（避免下游 app 來不及處理）。用 separate queue 區分 SMS vs status callback、long polling 減少空 API call、特別點出 FIFO 300 TPS 上限要分 queue。

判讀

Webhook 是 push、下游可能來不及、SQS 當 buffer 是常見 pattern。揭露 FIFO 的 300 TPS 上限是 hard limit、要設計分片才能擴張。

對應大綱

SQS 進階主題：Long polling / Standard vs FIFO。

下一步路由

回 SQS vendor 頁 與 3.2 durable queue。

引用源

• Handling High Volume Inbound SMS and Webhooks with Twilio Functions and Amazon SQS

觀察

Rapid7 Platform Software Architect 公開引述：「SQS 是我們架構的關鍵元件、讓我們 scale 到處理 10s of billions of messages per day。」是 AWS 官方文中具名客戶 quote、非 marketing 概括。

判讀

SQS 在百億訊息/日規模下仍可用、是 scale 的具體量級參考點。揭露 SQS request-based 計費在這個規模下、cost 模型該被認真評估。

對應大綱

SQS 進階主題：Cost 模型 / Standard queue。

下一步路由

回 SQS vendor 頁 與 0.6 成本取捨。

引用源

• Amazon SQS — 15 Years and Still Queueing