Cron job solution?

I am building a chat application but i want user to confirm in the first 10 mn of the chat if the user doesn’t click the confirm button the chat will end and it trigger a refund. any suggestion because i think create one cron job for every chat room would be very CPU intensive right ?

Add a timestamp and a field flagging the chat to the DB doc.

Then make a query to the DB every x minutes finding all the chats where the timestamp is longer than 10 minutes and have the flag as not confirmed. Then trigger the refund to all chats found.

You can use JavaScript setInterval to make the query.

1 Like

but would it CPU intensive or blocking request if we run it and query the collection every mn like that ?

Check out percolate:synced-cron if you want something more advanced.

1 Like

I guess the CPU impact will vary greatly depending on number of active users, the complexity of the refund function and finally the frequency you check it.

How precise the 10 minutes wait should be? Do you need to do it exactly on the 10 minutes mark or it can be flexible? 10 to 20 minutes. 10 to 30 minutes.

If you have to be precise you need to start a cron job for every user. Let’s say you have 100 concurrent users. 100 cron jobs due in the next 10 minutes. every one you’ll ned to access the DB to check if they had accepted the chat and generate the return. 100 times.
You can also stop the cron job if the chat gets accepted.

if you can be flexible you check the DB once every 5, 10, 15 minutes. and act on the chats that need to be refunded only.

The collection should have an index for the unconfirmed chat flag to can find the docs faster.

You can create a separate app just to make this check and update the DB. it can be on a different server if necessary.

1 Like

I really like

It is powerful enough for just about any situation, but easy to get started. Exactly what a great package should be :slight_smile:

1 Like

Set up a TTL index on a field in the collection (or another collection) and an observer to run when documents are expired (removed).

This puts the work involved in expiring documents inside the database engine, where it belongs, and a low-impact way of handling expired documents. You really don’t want to be managing cron jobs or polling the database for this use case.


Thank you the TTL index approach is very fresh approach and it sound very promising

1 Like

because i want to close the chat instantly when the user not able to confirm so it need to run every mn i never try to benchmark the performance so i never know. was thought of using another collection just to check that schedule.