Choosing a database to store the list, with fast writing and deleting elements?

Question

go

There is a certain object A and there are subscribers to change this object. Object A can change very often (sometimes even more than 1 time per second), and therefore fetching the list of its subscribers should work quite quickly. Subscribers can also subscribe and unsubscribe quite often to receive updates on any of the objects.
At the moment, there are no more than 400 objects A in the system at the same time, and the number of subscribers does not exceed 600 on average and 1000 at the peak (we expect growth). From practice, it will turn out that a small number of objects A (<10%) will be subscribed by most of the customers (100%), while the remaining objects of the subscription may not be at all.
So the question is: what is the best way to store all this? what data structure to make? Well, what to read, test?
The first thing that comes to mind is to take Redis and store a list of subscriber IDs by the key identifier A.id. However, I'm afraid there will be problems with changing the list after the next subscription / unsubscribe.
You can store everything in a traditional RDBMS, but then there will be brakes when getting the list.
ps. At the moment, we have such an implementation that clients (subscribers) themselves are periodically interested in whether something has changed. It seems that everything is not bad, but sometimes clients suffer from the fact that they do not receive information about changes in time. Well, then, I want to experiment.
pps Or maybe I'm complicating everything, and it will be enough just to store everything in a separate application as an array in a map, or something like that. Although it would be a shame if all this accidentally falls. It will probably be developed in golang, so options with built-in solutions will do.

Answer 1

Tarantool, Redis - their performance is enough for the eyes.
There will be no problems that you fear.
Moreover, if you have Go and it does not restart on every sneeze - why don't you store it in the Go program itself?