How to optimize the application with huge number of database requests per minute

Question

I have to provide free demo of some service to end users in my application. Free demo could be of 30 mins, 1 hours, 5 hours etc. (predefined time) for a new user for one time only.

User can also consume that time in parts. like in 30 mins of free demo, they can use like 10 mins today, 15 mins tomorrow and rest of the time on next day etc. Now If a user opt the free demo of 30 mins and logged in & using the service. I can restrict the user for 30 mins via his start time & end time. I can send them to payment page if sum of start & end-time is equals to 30 min.

Now problem arises with some uncertain conditions like what if user closes the browser or their internet stopped working or anything else at their end during their active session. In this, I can't calculate their consumed time because of lack of endtime.

Scenario could be like below (for 30 min demo).

UserID  StartTime           EndTime             Consumed(mins)
10      09-04-2015 10:00    09-04-2015 10:10        10
10      10-04-2015 05:00    10-04-2015 05:04        4
10      11-04-2015 07:46    11-04-2015 07:56        10
10      11-04-2015 10:00    // Browser closed or any uncertain condition
10      11-04-2015 11:00    // How to restrict user to use actual 30 mins because I do not have EndTime in above row to calculate Consumed mins.

I may have more than 100000 users at the time same to use our services, So I am finding an efficient solution for this.

As per my understanding, I can create a Separate Job to check user's LastActiviteTime and based on that I can update their Consumed(mins) in database. That Job would be executed every minute and also on the other hand, browser of each session user would update the LastActiveTime in database.

This can solve my problem but I'm not very sure about the performance of my application becuase of huge number of database request per minute.

Please advice.

Answer 1

I do not think making decisions about if trial time was exhausted on client is a good idea. This can be easily fooled and can't be calculated with some precision.

Since you have a web application, I guess, it would be much better to limit a number of API calls a trial user can make without payment. You can make some tests and map an average number of API calls to a time, an average user spends at your software.

Answer 2

You are correct in that you cant ensure logout with a web application, where you essentially download a client program and then make intermittent requests for data the server.

There are a few work arounds for this problem that I know of

1: define 'logged out' as automatically occurring after a period of inactivity

This may not be best for you with such short periods as 30min as a user who's computer crashes will use up actual time + inactivity timeout

2: use javascript to constantly poll the server 'i am logged in!' you can improve this with websockets or long polling

This gets you more time resolution than 1 but at the cost of constantly processing the messages

For your specific case I think you just need to define 'time used' in your terms of service to take account of the possibility of crashes using up a bit more time.

Either the customer loses out on a few min because you include the inactivity period, or they can possibly scam you for a few min because you measure to the last time you are sure they were logged in rather than to when you assume they are logged out.

Answer 3

Since users will be somehow authenticated during usage, you could "flag" trial accounts status and keep track of their activity:

• User A logs in.
• User A performs an action against the service
• A combination of the user ID + timestamp is tracked
• Check the earliest timestamp associated with the same user ID
• IF the check passes (the earliest and the current are within the allowed interval), perform the requested action
• ELSE you can deny the request (your trial "window" has expired).

This can get fancier and cover subscription plans and the like, it just needs a handful of easily handled flags. It's also tamper-proof to a certain degree, since it's all server-side (I'm not considering hacked account, but that's another issue).

This approach would start "counting" when users perform the first request. If you want to consider the interval start at the time of registration, you can simply "track" a fake action to provide you with a timestamp to compare against.

Answer 4

I suppose that with this number of users it is not hosting but dedicated servers where you can install everything you need to your service. If it is right my suggestion is to use some external storage like Redis where login token (or other user identifier that passed from client to server) will be the key and value is all data you want to know about the user including time left in demo.

Each time the request received from user you can update time elapsed in Redis without inserting junk data into database and overloading it with requests. And additional profit is that you can set when Redis record will be terminated it may be done automatically by Redis if you will not update termination date of the record.

In this case users may have time limit to use their demo and you do not need to do anything to implement it.