Not sure if I'm approching this the right way. Any poining in the right direction is greatly appreciated

Before anything, I legitimately have no idea if this is the right place to ask these sort of questions, if it isn't I guess downvotes for me.

I've been given a take home test, by a potential employer. The requirements themselves are pretty straight forward I suppose. I won't copy paste the whole thing as it's quite large.

Please implement a system where people can enter a shipping tracking code in a form and as a result they will see an estimated delivery date. The frontend is supposed to be connecting to the backend through a REST API. Please make sure that the data store in the backend can be replaced (e.g by a config). Implement two storage solutions that can be plugged in.Suggestions for data stores to implement are SQLite and file (CSV)

Please be careful about unit tests, commits and all those other pesky details. They matter.

I'm not here for things like "please write my code for me" or other stuff like that.

They hinted that they'd like it to be written in Laravel. I'm perfectly fine with that.

With that said, I've got a few questions about what approach I should take as I've never actually dealt with package tracking before.

Obviously it won't be as complex as a real system, but rather the more mellowed down "let's see if you're capable of doing it" sort of thing.

---

For argument's sake, assuming that it would be a large database, I wouldn't be remotely comfortable with storing them in CSV or SQLite for that matter. I don't exactly know what to go for here, something like TokuDB seems like a major overkill and something like NoSql I don't know how to write.

Would a good old InnoDB table do? Heck, even a MyISAM single table that simply stores the info about the package itself, just for reading, seems like a good idea, given that no caching would be involved. I hear MyISAM is quite fast when it comes to read/writes.

Would it be stupid of me to try and atomize the data a bit? Like have a table with countries, possibly a table with cities and all that stuff? Of course I could just throw it all in one table and call it day but that seems wrong on so many levels.

How would I go about writing unit tests for an API? It seems kind of an oxymoron, it's my understanding that unit tests are much smaller. Wouldn't it make more sense to write end-to-end tests or acceptance tests or something along those lines? Also how the heck do I mock an API? :\

And lastly, this part "Please make sure that the data store in the backend can be replaced (e.g by a config)". Again, never dealt with this before as it rarely(and by rarely I mean never, I've never seen this happen in the real world) happens that anybody would want to switch from one storage system to another, but unless I'm mistaking doesn't laravel offer this out of the box via configs?

Also, would using something like this be the right approach for changing between the storage mediums? Then again, it seems kinda of redundant to implement such an approach since an ORM comes out of the box. Aren't they more or less the same thing? In this case anyway.

via Chebli Mohamed