A versenyhelyzet kezelésének user oldalra kitolása azt jelenti, hogy sokszor kapja meg, hogy bocs már elkelt az időpont.
A queue garantálja az időbeli sorrendiséget, tehát az viszi az időpontot, aki előbb kattint, másrészt, szerinted: tegnap mi történt? A listát mire végiglapozod, hogy eljuss egy neked tetsző időpontra, ráböksz, már lefoglalták.
Azaz ugyanaz lenne az eredmény, sok ideges felhasználó feladja, anyázik és odamegy reg nélkül.
Messze nem ugyanaz, mert a rendszer végig elérhető és responsive marad, és visszajelzi a felhasználók felé a szükséges státuszokat.
A versenyhelyzet kezelésének user oldalra kitolása azt jelenti, hogy sokszor kapja meg, hogy bocs már elkelt az időpont.
Érdeklődve várom a szakmai javaslatodat, hogy tudod megoldani, hogy egy nem skálázható backend ne omoljon össze, nekem eddig terjed a szakmai tudásom a téren, szeretek újat tanulni. Amúgy a helyek két fázisú foglalása is pont az user oldalra tolja ki a versenyhelyzetet, annyi változik, hogy az előfoglalásnál kell ugyanezt a játékot játszanod real-time, pusztán azért szokták használni, hogy a fizetési szakaszban már biztos csak egy foglalás legyen egy helyre és ha sikerül a fizetés, akkor nyilván foglalt marad, ha nem, akkor timeout után visszakerül az előfoglalható helyek közé. Annyi a szerepe, hogy ne indulhasson két fizetési folyamat egy helyre, mert az szopás.