0

I have a question regarding the implementation of using a:

  • CosmosDB
  • Service Bus + DLQ

I have a Service Bus Trigger which triggers, does processing to incoming data, and then stores it in a CosmosDB with Upsert. If one message fails in the processing, I store it on a DeadLetter Queue (DLQ) which will be sent upon request at a later time. This will possibly lead to the problem that I will re-send an (much older) message from the DLQ which will override a "newer" object in the database. Today, I use a Table in order to store timestamps in order to make sure when an object was latest updated. A better way is to investigate a timestamp at the stored document vs. the Enqueued time property at the incoming ServiceBus message, however this does not work for a non-persistent Database.

Is there any "cleaner" ways to come around this issue?

rene
  • 41,474
  • 78
  • 114
  • 152
Lud1212
  • 117
  • 9

1 Answers1

2

Here are some aspects to help think about your solution:

  • Use a Service Bus transaction to ensure all the relevant work is done before completing the message. If the CosmosDB upsert fails, abandon the message for a retry.

  • Make sure that your design is idempotent. You can use the enqueued time and/or a correlation id to manage order to help implement the idempotence. I would add this as an array in the CosmosDB document and avoid using another data store to reduce possible points of failure.

  • Also make sure you have chosen the correct CosmosDB consistency level for your use case and if you are dealing with huge volumes, then you will need to think how important this feature is and possibly use your correlation ID in your partitioning strategy.

Murray Foxcroft
  • 12,785
  • 7
  • 58
  • 86