Examkin

Question

Difficulty: Very hardDecoupling Architectures and Event-Driven Messaging

A medical device manufacturer is building an IoT monitoring system on AWS to process state-change logs from thousands of diagnostic devices. The system must process status updates for each device chronologically to maintain an accurate device history. During peak usage, the system experiences brief, massive spikes in telemetry messages. The architecture must fan out these state-change events to two distinct backend systems: a real-time status-tracking service and a historical compliance auditing database. Which solution meets these requirements with the least operational overhead?

  1. A
    Publish the state-change events to a standard Amazon SNS topic. Subscribe two standard Amazon SQS queues to the topic, and configure the consumer applications to re-order the events chronologically using the message timestamps.
  2. B
    Publish the state-change events to an Amazon SNS FIFO topic. Subscribe one Amazon SQS FIFO queue for the status-tracking service, and subscribe the compliance auditing database's AWS Lambda function directly to the SNS FIFO topic.
  3. Publish the state-change events to an Amazon SNS FIFO topic. Subscribe two Amazon SQS FIFO queues to the topic, with one queue dedicated to the status-tracking service and the other to the compliance auditing database.Answer
  4. D
    Publish the state-change events to an Amazon Kinesis Data Stream. Configure a single AWS Lambda function to run continuously in a loop to poll the stream, process the events, and write them sequentially to both downstream services.

Answer

Publish the state-change events to an Amazon SNS FIFO topic. Subscribe two Amazon SQS FIFO queues to the topic, with one queue dedicated to the status-tracking service and the other to the compliance auditing database.
Publishing events to an Amazon SNS FIFO topic and subscribing two Amazon SQS FIFO queues is the optimal decoupling pattern. SNS FIFO topics preserve message ordering and deliver messages to subscribed SQS FIFO queues in a first-in, first-out manner. The device ID is mapped to the message group ID, ensuring messages for the same device are processed in order by the downstream consumers. This fully managed approach requires no custom polling logic, keeps operational overhead to a minimum, and handles traffic spikes seamlessly.

Step-by-Step Solution

1
Identify the core requirements: message ordering preservation per device, fan-out to two distinct services, spike resilience, and minimal operational overhead.
Limits the valid design choices to event-driven services that support FIFO delivery and fan-out natively.
We must filter out solutions that use standard queues (which do not guarantee ordering) or those requiring heavy custom container/compute management.
2
Evaluate the subscription constraints of Amazon SNS FIFO.
Rule out direct subscription of AWS Lambda functions or standard SQS queues to the SNS FIFO topic.
Amazon SNS FIFO topics only support SQS FIFO queues as subscribers to guarantee ordering preservation.
3
Analyze the operational overhead of the Kinesis and Lambda custom polling option.
Rule out the Kinesis solution due to the inefficient and expensive continuous polling loop implementation in AWS Lambda.
Continuous execution loops in serverless functions are a major cost and operational anti-pattern.
4
Confirm the capability of SNS FIFO to SQS FIFO integration.
Each SQS FIFO queue will receive identical ordered copies of the messages, preserving the FIFO ordering per Message Group ID (device ID) for each downstream application independently.
This satisfies all business and technical constraints with a fully managed serverless architecture.

Key Concept

Decoupling with FIFO ordering and fan-out.
Estimated Time:3m 0s
Rate this question

Topics

Decoupling Architectures and Event-Driven Messaging

More questions from this topic