I have an application that writes data to database. In case of network breakdowns, the connection to database gets lost & my db queries freezes the whole application.

So, in order to make it asynchronous, I've used a message queue mechanism to separate out the "db queries" part with my "core application part".

The problem is that until the database gets back online, all the data generated in mean time gets lost.

What kind of software design can help to tackle this problem ?

  • 2
    The question, as it is written, is just too broad to give one answer to. – Greg Burghardt May 6 '19 at 19:46
  • 1
    Your remark is not going to make your questions survival more likely, quite the opposite. – Doc Brown May 6 '19 at 20:56
  • As an aside, what do you mean by 'get lost'? Do you actually drop data if you can't perform a successful write? :O – Akshat Mahajan May 7 '19 at 2:11
  • @Akshat Mahajan Yes, the culprit is the message queue. Once its limit gets reached, it starts dropping data. – Rohit May 7 '19 at 3:50
  • @DocBrown Remark is just to bring reviewer's attention other than that it serves no purpose. And yeah, I did my research after writing this question & found out about NPR from Area51. That's all I'll say, rest reviewer(s) shall do what's right. – Rohit May 7 '19 at 4:03

Core of your problem is, by introducing the asynchronous message queue, your application does not get immediate feedback (like exception messages) any more if db queries start to fail. I see basically two conceptual options for handling this:

  • When the operations put into the message queue fail (like a database write operation), make sure the queue sends error messages for each failed operation back to the application, so the application can handle this.

  • Or, if you know for sure those network breakdowns occur only temporary, let the queue handle the problem. For example, it might be possible to add a local buffer the queue (maybe utilizing some local persistent storage) which is large enough to store the expected number of messages for the maximum expected break time interval.

Even for the 2nd approach, it might be a good idea to inform your application about network downtimes (by asynchronous messages/signals). Maybe it can switch into something like an "offline" mode and stops generating more messages, so the local buffer of the MQ won't get overloaded.

  • Since my application is a production application in a manufacturing industry, so, I can't stop the data generation(core application part), even if I set up some error acknowledge mechanism. I'll try to implement your 2nd idea, setting up local persistent storage as a buffer to store the messages & try to write them later in intervals. – Rohit May 8 '19 at 7:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.