Number of participants overflow

[vmendes]

Hi,

I tried this application with around 100 (real) participants, and here's my experience:

• The application stopped working as expected in a quiz of 17 questions
• On the second question, the countdown was already done (zero) and the question was still open to answer
• We waited for 30s so the answer could show up, but it didn't happen
• After that I cancelled the match and started over, it jumped to the second question as expected but was still open for answers.
• Then the number of answers exceeded the number of participants (it was over 150 answers with only 100 participants for the same question)

We tried again with different match slug, and it happened all over again. I was using the Developer plan on Sanity.io but I purchased the overusage limits just in case and noticed it did not passed 10% of max api requests. I was wondering if the backend api really supports the amount of parallel submissions for this app.

It's a bummer if you try to use it with real people, as we let many down. I wish I could have tested this app with some stress tool beforehand. Any suggestions?

Overall, great app but take my issue in consideration before you do production usage ;)

[vmendes]

Ok, so after some investigation, I managed to replicate the problem with some stress testing and my findings are:

• The Sanity plan that I was using (Developer) was up to 100 listeners (which may impact the concurrent calls)
• It looks like some clients were bombarding the server functions with too many calls. It's possible that:
  a. Some users were trying to click frenetically the choice cards and may have generated duplicated calls at some point
  b. Some issues with Android/iPhone browsers, generating more calls than needed (hard guess)
  c. To win the quiz, they have logged in more times in different clients (mobile + desktop or incognito tabs)
• The Studio (host) app was listening to a topic that checks every state change, so the quiz host was pulling too many local states updates, which then took a while to finish them all. This may be the reason why the countdown was over and the question was still open, as the call which received this update was still pending.

Something that I think could improve the scalability of the app:

• Support of maxParticipants env variable. But instead of limiting the usage (which is also an option), replace the listen/subscribe topic approach with letting the countdown be over then set the isCurrentQuestionOpen=false.
• Introduce the self-paced feature (as described on Challenge Option for Quiz Flow similar to Kahoot! #7), which will basically balance the load of too many requests. Then, when everyone finished all questions and/or times up, show final leaderboard.