Examkin

Question

Difficulty: MediumDecoupling Architectures and Event-Driven Messaging

An e-commerce company is designing an order processing application on AWS. When a customer places an order, the application must publish order events to multiple downstream services. The transaction service must process payments in the exact order they are received to ensure ledger accuracy. However, the shipping notification service and the analytics service can process events asynchronously without strict ordering requirements. If a service fails to process an order event after multiple retries, the event must be isolated for troubleshooting without blocking other orders.

Which TWO configurations should a solutions architect recommend to meet these requirements with the least operational overhead?

  1. Publish order events to an Amazon SNS FIFO topic. Subscribe an Amazon SQS FIFO queue for the transaction service, and subscribe standard Amazon SQS queues for the shipping and analytics services.Answer
  2. Configure a redrive policy on the SQS queues to redirect failed messages to a dead-letter queue (DLQ) after the maximum receive count is exceeded.Answer
  3. C
    Publish order events to a single standard Amazon SQS queue. Configure all downstream services to poll the queue simultaneously, relying on standard SQS ordering to process transactions in sequence.
  4. D
    Ingest all order events using an Amazon Kinesis Data Stream with provisioned shards, relying on the stream to automatically increase the shard count during peak traffic to prevent throttling.
  5. E
    Write transaction records directly to a primary Amazon RDS DB instance, and configure downstream services to poll a Read Replica for updates, using the Read Replica as the primary failover target if the primary database fails.

Answer

Publishing order events to an Amazon SNS FIFO topic with SQS FIFO and standard SQS queues subscribed, combined with configuring redrive policies to a dead-letter queue (DLQ) for failed messages.
Publishing events to an Amazon SNS FIFO topic enables message fan-out to multiple downstream queues while preserving ordering. Subscribing an SQS FIFO queue ensures the transaction service processes orders sequentially, while subscribing standard SQS queues for shipping and analytics allows them to run asynchronously without ordering constraints. Using SQS redrive policies to a DLQ isolates failed messages after a specified number of retries, preventing head-of-line blocking.

Step-by-Step Solution

1
Determine the event routing and fan-out mechanism.
Amazon SNS FIFO is selected as the publisher because it supports fan-out to multiple subscribers while maintaining strict message ordering and deduplication.
The system needs to send the same order event to multiple downstream systems (transaction, shipping, analytics).
2
Select the appropriate SQS queue types for each subscriber.
An SQS FIFO queue is configured for the transaction service to guarantee ordered processing. Standard SQS queues are configured for shipping and analytics to allow asynchronous, high-throughput processing.
The transaction service requires strict chronological order, whereas shipping and analytics do not.
3
Configure error handling and message isolation.
Enable a redrive policy on the SQS queues pointing to an SQS dead-letter queue (DLQ).
Failed messages must be isolated for analysis without blocking subsequent messages in the queues.

Key Concept

Decoupling event-driven architectures using Amazon SNS FIFO fan-out to SQS queues, combined with dead-letter queues (DLQ) for fault isolation.
Estimated Time:2m 0s
Rate this question

Topics

Decoupling Architectures and Event-Driven Messaging

More questions from this topic