Laravel Algorithm for taxi app

Question

I am trying to write a backend for a taxi service (university assignment) and I am stuck on the algorithm.

whenever a new client posts a request, all the taxi drivers nearby get an email notification and, for five minutes, I have to collect the positive answers (the ones who are willing to give a lift).

After five minutes, I have to match the customer with the best taxi driver who answered, based upon feedback and distance.

I have set up everything in Laravel 5.1, but don't know how to implement the "pool" of answers from drivers. Should I use a temporary MySQL table or opt for a temp file storage? Or design a different way of tackling with it?

• scriptin: I suggest always preferring a database over plain files. There are spatial functions in MySQL which can be helpful in your case.
• Washery: I know, but the this is I need to store the temporary answers from drivers and, once the match has been done, I need to delete the data associated to free space. That is why I think file storage could be better than a database temporary table (or a permanent one).
• scriptin: Mark the records with request id, and delete ones for which requests were resolved/cancelled. It won't get any harder than DELETE ... WHERE .... You'll have to delete files as well, and eventually you'll run into concurrency problems, which are much harder to solve with files.

Answer 1

Using the database has a bunch of benefits. Some of these benefits don't apply to a school project, but I'll list them anyhow.

1. If a driver is notified about two fares, make sure the driver isn't assigned both.
2. The state of the system is represented in fewer places.
3. Storing business rules makes changing business rules without a recompile more feasible. This isn't necessarily a win (it can encourage cowboy coding), but in the case of a project which will never have a version 2, that's moot.
4. A database schema is easier to create/adapt than a file system, which requires a file names and serialization.
5. Inspecting the current state of your system is easier with a database. Creating sophisticated queries (e.g., for debugging or to assist a help desk) is easier if the data is in the database.
6. A database will scale up more easily.

The main benefit of using a file system is that it may have a slightly lower start-up cost. This lower cost introduces a bunch of problems (which a database is designed to solve), but such problems may be unimportant in the case of a school project. Taking on a big chunk of technical debt to save a small amount of time isn't a big deal if you're creating a project that will never be maintained.

• Washery: Than you. I completely agree, a DB table is the best choice. However, regarding your first point, I think it is not feasible to keep trace of all requests, better check if a driver is performing a service instead and keep the "requests matching pool" table clean.
• Brian: @Washery: Ignoring point one causes nasty scaling problems. Consider the case of 5 people in the same town simultaneously requesting cabs. If their ranges perfectly overlap, then 4 of them will receive 0 cabs. If their ranges imperfectly overlap, then 4 of them will receive unnecessarily distant cabs. Note that overlapping ranges are not uncommon, in the case that people are requesting cabs from a transportation hub (though in most cases, such a service would be unused, since such hubs are always populated by waiting cabbies).