Examkin

Question

Difficulty: HardMessage-Based Integration using Amazon SQS and SNS

A developer is designing a logistics application. Real-time location telemetry events from fleet vehicles are published to an Amazon SNS topic. Two separate backend services need to process these events:

1. A routing analysis service that must process events in the exact chronological order they were generated per vehicle to calculate path history, and must prevent duplicate events from being processed.
2. An alerting service that checks for speeding and can process events in any order, but needs to receive all telemetry events.

The developer wants to implement a fanout architecture using Amazon SNS and Amazon SQS. Which two configuration steps should the developer perform to meet these requirements? (Select TWO.)

  1. Create an Amazon SNS FIFO topic, create two Amazon SQS FIFO queues (one for each service), and subscribe both queues to the SNS FIFO topic.Answer
  2. Set the vehicle's unique identifier as the Message Group ID when publishing the telemetry events to the Amazon SNS topic.Answer
  3. C
    Use a single static string as the Message Group ID for all telemetry events to ensure strict chronological ordering across the entire fleet.
  4. D
    Set the Amazon SQS queue visibility timeout for the routing service to be shorter than the maximum processing time of the consumer application to minimize processing latency for subsequent messages.
  5. E
    Configure the downstream AWS Lambda function consuming the routing queue with a short timeout, and use global state variables inside the Lambda execution context to track and deduplicate messages across separate invocations.

Answer

Create an Amazon SNS FIFO topic, create two Amazon SQS FIFO queues, and subscribe both queues to the SNS FIFO topic. In addition, set the vehicle's unique identifier as the Message Group ID when publishing telemetry events.
To implement a fanout pattern that preserves strict message ordering and deduplication, the pipeline must use an Amazon SNS FIFO topic and Amazon SQS FIFO queues. Since Amazon SNS FIFO topics only support SQS FIFO queues as subscribers, both queues in the fanout architecture must be FIFO queues, even if the alerting service does not strictly require ordering. To ensure that messages are ordered per vehicle while allowing concurrent processing of events from different vehicles, the vehicle's unique identifier should be used as the Message Group ID. This groups events by vehicle, serializing updates for each vehicle while allowing SQS to process multiple groups in parallel.

Step-by-Step Solution

1
Analyze the requirements for ordering and deduplication.
The routing analysis service requires message ordering and deduplication per vehicle. The alerting service does not require ordering but must receive all events. A fanout pattern with Amazon SNS and SQS is required.
This establishes that at least one queue must be FIFO, and a message grouping strategy is needed.
2
Select the appropriate SNS and SQS queue types.
An Amazon SNS FIFO topic must be used to preserve ordering. SQS Standard queues cannot subscribe to SNS FIFO topics, so both downstream queues (routing analysis and alerting) must be Amazon SQS FIFO queues.
This satisfies the AWS service limitation where only SQS FIFO queues can subscribe to SNS FIFO topics.
3
Determine the message grouping key strategy.
Set the vehicle's unique identifier as the Message Group ID when publishing events to the SNS FIFO topic.
This ensures chronological ordering of telemetry events is maintained per vehicle while allowing messages from different vehicles to be processed concurrently, avoiding performance bottlenecks.

Key Concept

End-to-end FIFO message delivery using Amazon SNS FIFO topics and Amazon SQS FIFO queues, ensuring message grouping by a high-entropy identifier to balance ordering and throughput.
Estimated Time:2m 30s
Rate this question

Topics

Message-Based Integration using Amazon SQS and SNS

More questions from this topic