If this is caused by a user client program (that is, you are called by mobile phones), and not by a browser, then why register them at all. Rather, just use HTTP authentication (either DIGEST or BASIC if you intend to use SSL, or your own scheme), and register them each time.
Then you do not need to worry about sessions, load balancing and failure, etc. Keep her stateless.
Addenda:
Of course, fewer database calls are better, this is just a general rule. But at the same time, many calls to the database are processed by cached pages on the database server or, possibly, by application caches, so that they never get to the database server. Thus, in some cases, especially single-row queries against an indexed column, database hits can be very cheap.
Now you can think about whether they are saved and easy to retrieve, which really is the difference between the cache bit of the database and a unique user session.
Well, first of all, the difference is in the data contract. A cached item has a lifespan that is directly proportional to the amount of memory you have and the amount of unclosed activity. Give it a small amount of memory, and the cache object probably has a very short lifespan. Give it a lot of memory, and a cached item has a much better chance of hanging itself. If the amount of memory for cached data is large enough so that re-activity for that data continues to use the cache, the cache is a big win. If your cache is processed so quickly that nothing is "in" the cache, then the cache is almost irrelevant. But the fact is that the system will work with or without a cache, a cache is just a performance increase.
However, the session has a different contract. Many sessions have a certain minimum life, usually measured in minutes: 10, 20, even 30 minutes.
This means that if a user clicks your site only once, you must allocate resources to that user, even if he never returns. You must, otherwise the session offer is effectively irrelevant.
If you get a lot of traffic, you get a lot of new sessions for management. Theoretically, in bad circumstances, sessions can splash unhindered. If you suddenly get 10,000 views on your site, you can manage the rest of these views for the minimum duration of your session. You must devote resources to them (memory or disk), you must track them, and then, inevitably, you must clean them.
A cache is a fixed resource. It only grows to the size that you customize it. You are not required to store anything in the cache, and, as discussed earlier, the system will work with or without the cache. Caches naturally process. If you get this surge of 10,000 views, they may roll your cache, but after that they leave no trace on your system. They can hit and leave after 1 or 2 minutes so that they are no longer seen.
Finally, with sessions, you need to share them between your infrastructure so that they travel with the user if they jump from machine to machine (for any reason). Caches do not. Ideally, you want the user to be local to the set of resources, so that the caches can do their job, but the system works regardless of whether they move or stay (it just works better if they stay, due to reusing the cache) . If you do not repeat your sessions, they do not work at all.
The database bit is stacked, they can be cheap, but they are never free. But the session also has its own costs, so it’s important to consider them and how they are applied in your architecture.