Amazon SQS 支援 FIFO 了：「FIFO (First-In-First-Out) Queues」。新的 FIFO Queue 有保證順序，但也因此效能上有限制：
In addition to having all the capabilities of the standard queue, FIFO (First-In-First-Out) queues are designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can't be tolerated. FIFO queues also provide exactly-once processing but are limited to 300 transactions per second (TPS).
可以看到舊版的 FAQ 對於 FIFO 的回答是 Standard Queue 會盡力做到 FIFO，但不保證：(出自 2016/08/26 的版本)
Q: Does Amazon SQS provide first-in-first-out (FIFO) access to messages?
Amazon SQS provides a loose-FIFO capability that attempts to preserve the order of messages. However, we have designed Amazon SQS to be massively scalable using a distributed architecture. Thus, we can't guarantee that you will always receive messages in the exact order you sent them (FIFO).
If your system requires the order of messages to be preserved, place sequencing information in each message so that messages can be ordered when they are received.
而現在則是名正言順的說有提供 FIFO 了：
Q: Does Amazon SQS provide message ordering?
Yes. FIFO (first-in-first-out) queues preserve the exact order in which messages are sent and received. If you use a FIFO queue, you don't have to place sequencing information in your messages. For more information, see FIFO Queue Logic in the Amazon SQS Developer Guide.
Standard queues provide a loose-FIFO capability that attempts to preserve the order of messages. However, because standard queues are designed to be massively scalable using a highly distributed architecture, receiving messages in the exact order they are sent is not guaranteed.
原來這個叫做 Delayed Queue，難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)
Netflix 發表了他們自己所開發的 Delayed Queue：「Distributed delay queues based on Dynomite」。
本來的架構是用 Cassandra + Zookeeper 來做：
Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.
但可以馬上想到不少問題，就如同 Netflix 提到的：
Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.
所以就改放到 Netflix 另外開發的 Dynamite 上：
Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.
後端是 Redis 與 Memcached 的系統，可以對抗整個機房從 internet 上消失的狀態。
在設計上則是「保證會跑一次」，也就是有可能會有多次的情況，用 Dyno Queues 系統的人必需要考慮進去：
4. At-least-once delivery semantics
雖然整篇講的頗輕鬆，但實際看起來還是很厚重... 暫時還是不會用吧 :o