Persistent queue at the front

What is a persistent queue? This is a queue in which events will not be lost if the application is restarted.

A persistent queue in the frontend (or mobile app) can only be used … while the frontend is running. Is it really that useful?

Let’s figure it out.

First, let’s figure out the options for using just queues at the front (everything that has been said about the front-end can also be safely applied to mobile applications).

Front-end queues can be useful for

  • reducing the overall peak per backend. Instead of executing many requests to the backend at the same time, we execute all requests for the front in the queue handler. In such cases, the interactivity of the application usually suffers slightly, but the peak load on the backends can be quite seriously blurred over time. The RPS metric in this case means “users (applications) per second”.

  • organizing batching of requests. While the next request to the backend is being executed, the front accumulates the next requests in the queue. Then it executes them in one package (of course, the backend API should be able to do this).

That is, as we can see, the queue at the front is a very useful tool in itself. If someone is not familiar with this pattern, I highly recommend trying to use it when building mobile applications / front.

What can we get from a persistent queue?

Of course, the problem of backward compatibility of application versions! 🙂 Each application update should keep in mind that it may have to process tasks from the queue of the previous version. However, this is not such a big problem. Let’s look at useful applications.

Let’s look at a few examples.

Likes, views, etc.

The user views the news feed, social network feed, etc. In the process of viewing, he puts likes and dislikes. Save information about the decisions he made (taply (id: решение)) in a persistent queue – an almost ideal architectural solution:

  • if at the moment there is a connection to the Internet, then the information about the like will go to the server with a minimum lag;

  • if there is a problem with the connection, then the queue handler will execute the task when the problems go away (after a few seconds, minutes). Perhaps even another day.

Yes, theoretically, information about the decision made by the user may never reach the server, so it is not worthwhile to conduct, say, financial transactions of the user through such a tool.

Although … In some cases, it is for finance that a persistent queue is also suitable.

Payment terminals

Imagine a terminal that accepts banknotes, prints a check and transfers money to an account. Not an ATM, but, for example, a terminal a la Qiwi.

If the terminal does not have a connection with the outside world at a given time, then it may well accept money from the user, issue him a check. The transaction will be executed when the connection appears.

If you look at your mobile application or website, then, with a high degree of probability, you will find places where you can use a persistent or regular queue and improve the friendliness of the application to the user, and somewhere to smooth out peaks in the load on the back.

But in all cases where queues are used to aggregate requests, it is important to remember about idempotency.


Wikipedia: “Idempotence – the property of an object or operation, when reapplying the operation to the object, give the same result as when the first one. The term was coined by the American mathematician Benjamin Pearce in articles from the 1870s. “

That is, the backend front-end request handler should keep in mind that communication between it and the application may be unstable. As a result, requests may be repeated.

Proactive state setting

By putting a like, the user should see the result immediately. Even if this like is physically placed later. It follows from this that user actions, conducted through the queue, in some cases should change the local state immediately.

This can lead to the fact that reloading the application with an unparsed persistent queue will show the user that the action has not yet been taken.

You can also combat this by adding persistence to the state. Or you can … leave it as it is. For cases where this does not seem like a big problem.


For many popular frameworks, there are many solutions that implement persistent and non-persistent queues as framework extensions.

If there is no queue for your framework, then it is quite easy to write it yourself.


The rather simple architectural technique described in the article will allow you to build more user-friendly applications / sites. Many mobile applications could be improved using this technology and instead of showing “spin-loaders” or screens with progress bars, react to user actions instantly. But, alas, such approaches are rare in life.

Perhaps this article will help to reduce the number of seconds that the user spends waiting in front of your application, and he will spend the saved time on giving a good rating in the store? Who knows…

Similar Posts

Leave a Reply