FEATURE: Voting system about 30-seconds-of-interviews HOT 7 CLOSED

Voting systems exist in so many websites and projects, I suspect we are overthinking part of this.

from 30-seconds-of-interviews.

seriously the three best courses I ever took were problem solving, discrete structures, and a few design courses(grouping them because I'm not sure which helped most...) but sadly the biggest thing I learned was from the school of hard knocks:

Design to your failures!

from 30-seconds-of-interviews.

There's a couple of question you should ask at the start of any design process:

• What is it?
• How do we identify it?
• How do we identify them if we want to?
• Do we prevent repeats?
• How much can they do it?
• What would prevent them from doing it?

Answering these questions in order kind of makes it easier to design features in the long run:

• It is a voting system for ranking questions and answers for curation
• Everything would need a unique identifier so we can tell each question apart
• Every person would need something unique about their session with our site
• We should make it anonymous to the extent of generating a UUID and storing it in a forever cookie for our domain(this can lead to abuse)
• We might want people to vote for a question multiple time for relevance to them on a scale of 1 through 20(like medium claps)
• We can keep a server statistics table that would track their votes per unique question identifier and user identifier in the database

Next we approach storage:

• Where can we store it?
• Is there a way to store it only on the client side?
• Is there an advantage to store it on the server?
• Would there be an abuse case?
• Where should we store it?

And there's a LOT of options here so that also garners discussion but some baselines are:

• Somewhere any server shard can access it, so not on the server handling the request
• Cookies could work, but it would get a little hard to track. Local storage is also doable. User modification could lead to abuse. That's why client storage is usually only used for identification information after first visit
• Yes, we can have a lot more granular control over every aspect of what/who can access and modify the data, preventing abuse cases of questions being skewed
• If we store it on the client they could just reset the data and make our server think it's a new person. If we tie it to an IP address we lock out other people in the same physical location. On the storage medium it would mean only a full take over could cause the problem
• Probably on a storage medium accessible to the server but not to anyone else. A database would be overkill here. A file server might lead to transaction loss, but no matter what it's pretty agreed upon that server controlled access is the rule of thumb for this. We need to investigate further if we need atomic control

Next comes designing to failure:

• With the abuse cases above, is there a way to prevent it?
• How strong do the resources need to be?
• At what scale does this resource fail?
• At what access control does this resource do to much?
• At what point do we lose track of the user?

Those last questions can't just be answered by a storage expert. They need to be answered by the whole design team and bears a lot of discussion

from 30-seconds-of-interviews.

I agree with @skatcat31, but I also think that it would be worth it to give it a shot. (i.e. using the free tier on pusher and see how well it works out)

and what exactly do you mean by that @fejes713 ? ⬇️

The main problem is how to sync everything together so when somebody PR's new question, that some question goes into the database on the server while server maintains upvotes of other questions?

from 30-seconds-of-interviews.

@flxwu I'll answer this in the newest issue.

from 30-seconds-of-interviews.

I'm curious if we could implement this with OAuth using twitter's API and possibly Amazons Lambda free tier for Node?

from 30-seconds-of-interviews.

We're moving discussion to #24

from 30-seconds-of-interviews.