-1

Currently we have an application that doesn't scale well because of multiple concurrent updates to a table which gets locked. The tech stack is ASP.NET and backend is in SQL Server.

To avoid database access I am considering using NoSQL as a message queue where a producer service allocates tasks based on business logic into different message queues in Redis. Any recommendations would be appreciated.

Proposed architecture

A user logs in and the server creates a consumer process which reads the MQ, and starts working on the Task. It makes only two database updates - one registering the logged in user and other creating a new entry in the Task table. All consequent updates (quite a few ) are updated in Redis. At the end of the Task, the task object with all the new details is pushed to another queue for persistence to the RDMBS where the Task table is updated with all other data.

2

You don't provide enough information bout your system to recommend a solution.

However, using a (two!) databases as a queue is less good than using a queue as a queue.

In addition I would say you only need queues where you have 'long running processes' which are triggered faster than they can complete. I dont see where in your app you have this?

It seems to me that you should be able to fix a table lock issue by redesigning the table and SQL a bit, not introducing another DB and a cache system

1

Wouldn't it be better to just write code to allow your app to use more databases and to switch users between databases? With MQ you're going to add a lot of logic, and other problem with this approach is that your users won't be probably able to re-start already started edits untill all the data would be saved into the DB.

Or you can create new table on each user login, then push changes at the end... this way you'd probably be able to limit main table writes, and users won't need to wait untill the queue is empty before loading their already saved work, etc.

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.