Cloud as a Story - Vunvulea Radu

In the last post, we talk about queues where the ordering of messages are guaranteed (FIFO). Even if we have messaging services where FIFO is guaranteed at queue level, this is not enough to ensure that we consume the messages in the order they were added to the queues. The challenge for a queue that offers a FIFO is the number of consumers that could be in parallel. To guarantee that the FIFO is fully respected on the consumer side you need to have only ONE consumer or to assume that there are no exceptions or errors that can occur on the consumer side while a message is consumed. The flavour related to how the FIFO is defined as functionality inside a queue service is between ‘delivery guarantee’ and ‘guaranteeing message delivery in the same order that they were pushed’. It is not the same to have a system that guarantees the FIFO for message delivery vs the order in which the messages are processed. In the end, with a FIFO that guarantee the message delivery, if you have onl

Nowadays, most of the systems that are running inside a cloud provider like AWS or Microsoft Azure are using in one way or another a messaging system. Many people forget that not all the time a queue guarantee FIFO. Things are becoming more sophisticated, at the moment in time when you integrate the queue with other systems. You might realise that even if your queue is supporting FIFO, the integration with other cloud services will not enable you to use queue with FIFO guarantee. Because of this, I decided to write this short blog post that highlights things that might go wrong when you need a FIFO inside AWS or Microsoft Azure and how you could tackle them. AWS and FIFO At this moment in time (January 2020) the AWS services that manage messages are: AWS SQS AWS MQ AWS SNS (simple event/message routing solution) NOTE: We don’t take into consideration AWS Kinesis and AWS IoT Message Broker because they are more specific for events handling and IoT solutions. From