Examkin

Question

Difficulty: HardDecoupling Architectures and Event-Driven Messaging

A logistics and supply chain enterprise is building a package tracking system. When a package's delivery status changes, three distinct downstream systems must be updated: a real-time customer tracking portal, an analytics data warehouse, and an automated customer SMS notification service. The sequence of status updates must be strictly preserved on a per-package basis to prevent displaying incorrect states (such as showing 'Delivered' before 'In Transit'). The SMS notification service occasionally experiences intermittent downtime, and its messages must be retried independently without delaying processing for the tracking portal or the data warehouse. Which architecture meets these requirements with the least operational overhead?

  1. A
    Publish status updates to an Amazon SNS standard topic. Subscribe three Amazon SQS standard queues to the topic (one for each downstream system), and have each system consume messages from its respective queue.
  2. B
    Publish status updates to a single Amazon SQS FIFO queue. Configure a single AWS Lambda function triggered by the queue to sequentially call the APIs of all three downstream systems, retrying the entire execution block if the SMS service fails.
  3. Publish status updates to an Amazon SNS FIFO topic. Subscribe three separate Amazon SQS FIFO queues to the topic (one for each downstream system), and have each system consume messages from its respective queue.Answer
  4. D
    Publish status updates to an Amazon Kinesis Data Stream. Configure three consumer groups using the Kinesis Client Library (KCL) to process the stream, and manually increase the shard count during SMS service outages to handle delivery backlogs.

Answer

Publish status updates to an Amazon SNS FIFO topic. Subscribe three separate Amazon SQS FIFO queues to the topic (one for each downstream system), and have each system consume messages from its respective queue.
The solution utilizing an Amazon SNS FIFO topic fanned out to three separate Amazon SQS FIFO queues successfully meets all constraints. SNS FIFO maintains ordering across the fan-out boundary, and the SQS FIFO queues maintain strict order per message group (using the package ID as the MessageGroupId). Crucially, having separate SQS FIFO queues for each service ensures that if the SMS service goes down, messages accumulate in its specific queue and can be retried independently without blocking the tracking portal or the data warehouse.

Step-by-Step Solution

1
Analyze the fan-out requirement.
The message must be fanned out to three distinct downstream consumers (customer portal, analytics warehouse, SMS service) in a decoupled manner.
This establishes that a publish-subscribe pattern is needed.
2
Analyze the ordering requirement.
Status updates must be processed strictly in sequence per package.
This requires first-in, first-out (FIFO) message processing, ruling out standard queues and topics.
3
Analyze retry and outage isolation.
One downstream consumer (SMS service) experiences downtime. Its failures must be retried without impacting the other two consumers.
Each consumer needs its own dedicated queue so that backlogs or errors in one consumer do not affect the throughput of the others.
4
Select the optimal serverless AWS services.
Amazon SNS FIFO fanning out to multiple Amazon SQS FIFO queues provides both ordered delivery and isolated buffering with minimal operational overhead.
This avoids the operational complexity of managing custom consumer groups in Kinesis or writing complex retry logic in a coupled Lambda function.

Key Concept

Combining Amazon SNS FIFO and Amazon SQS FIFO queues in tandem allows for ordered message fan-out and decoupled consumer processing, isolating failures and retries for individual subscribers.
Estimated Time:2m 30s
Rate this question

Topics

Decoupling Architectures and Event-Driven Messaging

More questions from this topic