Message Queue or DataBase insert and select

I am designing an app开发者_如何转开发lication and I have two ideas in mind (below). I have a process that collects data appx. 30 KB and this data will be collected every 5 minutes and needs to be updated on client (web side-- 100 users at any given time). Information collected does not need to be stored for future usage.

Options:

1. I can get data and insert into database every 5 minutes. And then client call will be made to DB and retrieve data and update UI.

2. Collect data and put it into Topic or Queue. Now multiple clients (consumers) can go to Queue and obtain data.

I am looking for option 2 as better solution because it is faster (no DB calls) and no redundancy of storage.

Can anyone suggest which would be ideal solution and why ?

I don't really understand the difference. The data has to be temporarily stored somewhere until the next update, right.

But all users can see it, not just the first person to get there, right? So a queue is not really an appropriate data structure from my interpretation of your system.

Whether the data is written to something persistent like a database or something less persistent like part of the web server or application server may be relevant here.

Also, you have tagged this as real-time, but I don't see how the web-clients are getting updates real-time without some kind of push/long-pull or whatever.

Seems to me that you need to use a queue and publisher/subscriber pattern. This is an article about RabitMQ and Publish/Subscribe pattern.

I can get data and insert into database every 5 minutes. And then client call will be made to DB and retrieve data and update UI.

You can program your application to be event oriented. For ie, raise domain events and publish your message for your subscribers.

When you use a queue, the subscriber will dequeue the message addressed to him and, ofc, obeying the order (FIFO). In addition, there will be a guarantee of delivery, different from a database where the record can be delete, and yet not every 'subscriber' have gotten the message.

The pitfalls of using the database to accomplish this is:

• Creation of indexes makes querying faster, but inserts slower;
• Will have to control the delivery guarantee for every subscriber;
• You'll need TTL (Time to Live) strategy for the records purge (considering delivery guarantee);