How should a solutions architect refactor this workflow to prevent the creation of multiple orders?

Explanations:

Kinesis Data Firehose is designed for data ingestion and transformation, not for reliable message delivery or processing payment transactions. It doesn’t guarantee order or deduplication, which is critical in this scenario to prevent multiple orders.

While using AWS Lambda to handle order processing might help centralize the workflow, it does not inherently prevent duplicate orders. If a timeout occurs, the user may still resubmit the order, leading to multiple entries since there’s no mechanism in place to check for existing orders before creating new ones.

Sending a message to Amazon SNS does not provide guaranteed message order or delivery assurance needed for payment processing. Additionally, SNS is not designed for deduplication of messages, which means duplicate orders could still occur if users resubmit.

Using Amazon SQS FIFO queues allows for ordered and exactly-once message processing, which is essential for this workflow. By storing the order in the database first and then sending a message to SQS, the payment service can retrieve the order in the correct order and prevent duplicate orders. The FIFO queue ensures that messages are processed in order and once, which directly addresses the issue of multiple orders being created on resubmission.