I am designing a delivery app where a Requester requests a thing from his mobile and the request is sent to multiple Agents on the field. When one Agent accepts the request, he will be assigned to the Requester and is expected to make his delivery.
I want a few Suggestions for Architecting this system. I am using the .Net Stack. Here are a few challenges:
1) At any point in time, only 5 agents will be notified. In case none of them accept the request, the request will be sent to 5 more. The agents who were notified for a particular request will be recorded in the database. In case an agent accepts a request, the database will be updated. In case after 10 seconds none of the agents accept the request, the windows service will send the request to next 5 agents.
Question: Will it be right to keep scanning the database with queries every 5 seconds using a windows service to see if the request has been accepted? The System has to be designed for heavy load.
2) The Requester can schedule a request.
Question: Will it be right to keep scanning the database with queries every 5 seconds to see if the scheduled time has approached?
I am using ASP.Net WEB API to receive info from the mobile, FCM to send notifications to the mobile and windows sevice to acomplish the above 2 tasks.
Please recommend an optimal approach, architecture, and technologies to be used to accomplish this.
2
Will it be right to keep scanning the database with queries every 5 seconds using a windows service to see if the request has been accepted?
When in doubt, push information instead of pulling it. You get the information that the request has been accepted, presumably from your web API. When you handle that message to put it in the database, you should also forward it on to anyone else who is listening.
There will be concurrency issues, so using your database’s constraint checking is a good idea. Any other attempts to accept the request should fail and warn the user.
Will it be right to keep scanning the database with queries every 5 seconds to see if the scheduled time has approached?
Instead of scanning, create a scheduled task. There are a lot of libraries with this functionality; Hangfire seems like a solid choice. When you get the message to schedule a request, queue a task to handle it at whatever time was requested.
3
Alternatively you can use some kind of queuing service like Amazon web services SQS or rabbitMq to keep the request around (across multiple instances of your service) until your request is accepted. Your database only has to be updated then, when the request is delivered to an agent (e.g. a table called “offers”) . The message can also hold the list of the agents that already got the request. When your request is accepted you can delete it from the queue and mark the “offers” as declined/expired/accepted. Your agents should be notified with some service like mqtt when an offer is available or not available anymore (because somebody else has accepted it).