-1

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.

delta-nada
  • 37
  • You are building a distributed data store. Consider the CAP theorem and determine what you can sacrifice. Most often Availability and Partition tolerance are picked, and Consistency is degraded to "eventual consistency". Is this the right choice in your circumstances? – 9000 Jan 24 '17 at 19:24
  • 1
    What are the concerns that downvoters have over this question? I'm sure this user would like to know what they can do to improve it. – Thunderforge Jan 24 '17 at 22:41

2 Answers2

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.

Andrew
  • 671
  • 4
  • 11
  • 1
    OTOH scanning a database may be very efficient if the table to be scanned is small enough to fit in RAM and is properly indexed, or even index-organized. – 9000 Jan 24 '17 at 19:26
  • @9000 That's definitely true, but I would worry about having issues scaling. I would definitely consider scanning, but the added complexity of creating extra processes (Windows services) and added load on the database makes me wary. Also, parallelism, performance, and scheduling are an unholy trinity of debugging pains. A problem that only shows up under load, with processes racing in a certain way, and intermittently would be a pain. – Andrew Jan 24 '17 at 19:42
  • 1
    It would be great if the problem could be solved by queues alone. The consistency is eventual: several agents could say they're picking a task, then notified whether they succeeded, or another agent sent a request earlier and was given the task. Storing the picture of actual tasks underway in a DB table could still be useful for many things, and looking at it occasionally might speed things up. Depending on load, of course. A light query once in 5 seconds is peanuts for any serious DB, provided that it's really one query, not e.g. one per client. – 9000 Jan 24 '17 at 19:56
2

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).

Hendrik Marx
  • 179
  • 2