SQS

In my last post, I implemented a message queue which decoupled our application and provided a level of redundancy for our messages. But what about messages that are not processed successfully? This could occur for a number of reasons there might be an issue with the consuming application, a network issue or even an invalid message request.

A Deadletter queue, also known as an undelivered-message queue is a holding queue for messages that cannot be delivered to their destination. They provide a mechanism for persisting your failed messages without continually trying to process the same message. The deadletter queue could then be monitored and any failed messages can be examined and appropriate corrective action taken.

deadletterqueuesitecore

Continue reading →

In my previous post, I looked at message queues and how they can be utilized in your solution architecture. In the second part of this series, I will explore how you can add messages to a Message queue (Message Publisher) and Consume messages (Consumer) from a message queue with Sitecore and AWS SQS.

Using the example of an Events Booking site where a user finds an event they are interested in complete an event registration form which gets submitted to Event Bookings Application via an API. The Booking Application is known to go down and it is not uncommon to run into connection issue with the API causing booking requests to get lost. The Booking Application is old and unreliable and occasionally goes down.

By adding a Message Queue we decouple the website from the booking application and provide a level of resilience. If an outage does occur or there is an API connection issue instead of messages being lost they will be persisted on the queue. When the booking application comes back online or connection has been restored the messages on the queue will get processed.

SitecoreMessageQueues