4

I have a subscription model, and want to perform renew-related logic like issue new invoice, send emails, etc. For example, user would purchase the subscription today, and the renewal is in a year's time. I've been using an Azure Queue recently, and think it would apply for such a renewal.

Is it possible to use the Azure Queue by pushing messages using BrokeredMessage.ScheduledEnqueueTimeUtc (http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.scheduledenqueuetimeutc.aspx) for such long term scheduled messages?

I've used it for shorter-term, like sending notifications in 1 minute time and it works great.

This way, I can have even multiple processes listening to the queue, and be sure that only one process would perform the renewal logic. This would solve a lot of locking-related problems, as that is kind of built-in the Azure Queue via leasing and related features.

astaykov
  • 30,768
  • 3
  • 70
  • 86
Karl Cassar
  • 6,043
  • 10
  • 47
  • 84

1 Answers1

10

Yes, you can use it for long-term scheduling, scheduled messages have the same guaranties as normal ones. But there are few things you need to be aware of:

  • ScheduledEnqueueTimeUtc is a time when message is going to be available (within hundreds of miliseconds) on the queue but not necessary delivered, this depends on load and state of the queue. So it's fine for business processes but not for time sensitive (milliseconds) usage. Not a problem in your case, unless your subscription cancellation is really time sensitive.
  • It affects your storage quota ( Not really a problem with current quotas, but if you think about years this might be a problem)
  • As far as I'm aware you can't access scheduled messages before ScheduledEnqueueTimeUtc, they are invisible.

Extremely awesome source of informations on azure messaging

From technological perspective it's fine but in your case I would also think about other potential problems if you think about years:

  • Message versioning
  • What happens when you would like to change Azure to something else (AWS?)
  • What if you decide to change in next year Azure Service Bus for NServiceBus
b2zw2a
  • 2,663
  • 15
  • 15
  • I'm considering a different approach to this, because it can have a lot of pit-falls as you said. Probably I'm trying to use database transactions to serve the same purpose. My main issue was that no two processes would process the same notification message / renewal twice. – Karl Cassar Nov 14 '14 at 09:52
  • Not sure what is you scale, but if it's reasonable you can run daily job which would either process renewals or simple add the renewal message to a service bus queue. This way you have a bit of both worlds - manageable time scale and At-Least and At-Most Once processing. – b2zw2a Nov 14 '14 at 09:56
  • 2
    Do we have an idea of how far ahead in time can we schedule a message using ```ScheduledEnqueueTimeUtc``` and continue to expect reliable delivery ? Days, weeks , months? – Sau001 Feb 12 '20 at 13:14