Examkin

Question

Difficulty: MediumDecoupling Architectures and Event-Driven Messaging

A ride-sharing platform is designing an event-driven system to process ride status updates (such as requested, accepted, driver_arrived, and ride_ended) sent from driver mobile applications. To maintain a correct trip history, updates for each specific ride must be processed in the exact sequence they are generated. The platform must handle sudden spikes in traffic during peak hours without losing messages, and the upstream ingestion layer must be decoupled from the downstream processing application. Which solution meets these requirements with the least operational overhead?

  1. A
    Publish the updates to a standard Amazon SNS topic. Subscribe a standard Amazon SQS queue to the topic, and configure the downstream application to process messages from the queue, relying on the queue's default configuration to preserve ordering.
  2. B
    Ingest the updates through an Amazon Kinesis Data Firehose delivery stream, configure it to buffer the events, and write them directly to an Amazon DynamoDB table with strong consistency enabled to ensure sequential updates.
  3. Publish the updates to an Amazon SNS FIFO topic. Subscribe an Amazon SQS FIFO queue to the topic, and configure the downstream application to process messages from the queue using the ride ID as the message group ID.Answer
  4. D
    Store the incoming updates in an Amazon ElastiCache for Redis cluster, and write a custom multi-threaded application on Amazon EC2 to continuously poll the cache and process updates in sequence.

Answer

Publish the updates to an Amazon SNS FIFO topic. Subscribe an Amazon SQS FIFO queue to the topic, and configure the downstream application to process messages from the queue using the ride ID as the message group ID.
The correct solution uses an Amazon SNS FIFO topic subscribed to by an Amazon SQS FIFO queue. SNS FIFO and SQS FIFO queues guarantee first-in, first-out (FIFO) delivery within a message group. By setting the ride ID as the message group ID, the platform ensures that updates for any single ride are processed in the order they were sent. This serverless solution handles scaling and message buffering automatically, minimizing operational overhead.

Step-by-Step Solution

1
Analyze the requirements for message ordering and decoupling.
Identified that the solution must guarantee strict ordering of messages per ride ID (sequence of status updates) and decouple upstream mobile apps from downstream processing.
This helps narrow down the choices to AWS messaging services that support FIFO (First-In-First-Out) capabilities.
2
Evaluate the capabilities of Amazon SNS and SQS for ordering.
Standard SNS and SQS queues do not guarantee ordering, whereas SNS FIFO and SQS FIFO queues guarantee strict ordering of messages within the same message group.
The ride ID must be used as the message group ID to ensure that messages belonging to the same ride are processed in sequence.
3
Select the option with the least operational overhead.
The serverless combination of SNS FIFO and SQS FIFO requires no infrastructure management and satisfies all decoupling and ordering constraints.
Custom solutions using ElastiCache or other databases require provisioning and management of compute resources, resulting in higher operational overhead.

Key Concept

Decoupling event-driven architectures requiring strict message ordering using SNS/SQS FIFO.
Rate this question

Topics

Decoupling Architectures and Event-Driven Messaging

More questions from this topic