SQS queue giao mỗi message cho một consumer và message bị xoá sau khi xử lý; khi nhiều ứng dụng cùng cần đọc toàn bộ luồng sự kiện, cần một data stream lưu giữ record để mọi consumer cùng đọc.

Ba ứng dụng của MFTECH đều cần nhận toàn bộ sự kiện mua hàng. Mô phỏng dưới đây gửi 6 sự kiện của ba người dùng (A, B, C) lần lượt vào SQS và Kinesis Data Streams để so sánh dữ liệu mà mỗi ứng dụng nhận được:

Các đặc điểm của Kinesis Data Streams thể hiện trong mô phỏng:

• Stream được chia thành các shard. Producer gửi mỗi record kèm một partition key; Kinesis băm key bằng MD5 để xác định shard. Các record cùng key được ghi vào cùng một shard, do đó các sự kiện của một người dùng luôn giữ đúng thứ tự.
• Record không bị xoá sau khi được đọc. Mỗi ứng dụng (consumer) tự quản lý vị trí đọc. Record được lưu giữ mặc định 24 giờ, có thể tăng tới 365 ngày (tính phí bổ sung khi vượt 24 giờ), do đó ứng dụng gặp lỗi có thể đọc lại dữ liệu.
• Consumer có thể là ứng dụng tự phát triển hoặc Lambda: event source mapping của Lambda tự động poll từng shard, đọc record theo batch và gọi function với từng batch. Bảng xếp hạng của chương trình khuyến mãi MFTECH chỉ cần kiến trúc serverless Kinesis → Lambda → DynamoDB, không cần quản lý EC2 instance.
• Số consumer xử lý song song bị giới hạn bởi số shard. Với Kinesis Client Library (KCL), mỗi shard tại một thời điểm chỉ gắn với một worker thông qua một lease (một worker có thể giữ nhiều lease); thêm worker nhiều hơn số shard không làm tăng độ song song. Với Lambda, event source mapping xử lý record của mỗi shard theo thứ tự; thiết lập ParallelizationFactor (từ 1 mặc định tới 10) cho phép tối đa 10 batch đồng thời trên mỗi shard, và Lambda vẫn giữ thứ tự ở cấp partition key. Để xử lý nhanh hơn, cần thêm shard.

MFTECH giám sát 5.000 máy POS tại các cửa hàng, mỗi máy gửi dữ liệu mỗi phút. Dữ liệu của từng máy phải được xử lý theo thứ tự, độc lập với máy khác, và số consumer cần mở rộng tới xấp xỉ số máy. Kinesis với partition key là mã máy giữ đúng thứ tự, nhưng số consumer song song chỉ bằng số shard (ít hơn nhiều so với 5.000 máy). SQS FIFO với message group ID là mã máy phù hợp hơn: các message cùng group luôn được xử lý lần lượt, đúng thứ tự, không có hai message cùng group được xử lý đồng thời; các group khác nhau được nhiều consumer đọc cùng lúc, nên độ song song tăng theo số group. Nếu mọi message dùng chung một group ID, toàn bộ queue chỉ được xử lý tuần tự; SQS standard không đảm bảo thứ tự.

An SQS queue hands each message to one consumer, and the message is deleted after processing; when many applications all need the full stream of events, you need a data stream that retains records for every consumer to read.

Three MFTECH applications all need to receive every purchase event. The simulation below sends 6 events from three users (A, B, C) to SQS and to Kinesis Data Streams in turn, to compare the data each application receives:

The characteristics of Kinesis Data Streams shown in the simulation:

• A stream is divided into shards. The producer sends each record with a partition key; Kinesis hashes the key with MD5 to determine the shard. Records with the same key are written to the same shard, so one user’s events always stay in order.
• Records are not deleted after being read. Each application (consumer) manages its own read position. Records are retained for 24 hours by default, extendable up to 365 days (with additional charges beyond 24 hours), so a failed application can reread the data.
• A consumer can be a self-developed application or Lambda: the Lambda event source mapping automatically polls each shard, reads records in batches and invokes the function with each batch. The MFTECH promotion leaderboard needs only a serverless Kinesis → Lambda → DynamoDB architecture, with no EC2 instances to manage.
• The number of parallel consumers is bounded by the shard count. With the Kinesis Client Library (KCL), each shard is bound to only one worker at any given time by a lease (a worker can hold several leases); adding more workers than shards does not increase parallelism. With Lambda, the event source mapping processes the records in each shard in order; the ParallelizationFactor setting (1 by default, up to 10) allows up to 10 concurrent batches per shard, and Lambda still processes records in order at the partition-key level. To process faster, add shards.

MFTECH monitors 5,000 point-of-sale terminals in its stores, each sending data every minute. Each terminal’s data must be processed in order, independently of the others, and the number of consumers must scale to roughly the number of terminals. Kinesis with the terminal ID as the partition key keeps the order, but the number of parallel consumers only equals the number of shards (far fewer than 5,000 terminals). An SQS FIFO queue with the terminal ID as the message group ID fits better: messages in the same group are always processed one at a time, in strict order, never two at once; different groups are read by several consumers simultaneously, so parallelism grows with the number of groups. If every message uses the same group ID, the whole queue is processed sequentially; an SQS standard queue does not guarantee order.