[Clarence]

Att ha en subscriber-modell innebär ingen skillnad i hur du lagrar informationen (db, memcache). Det innebär inte nödvändigtvis heller någon förändring i hur du hämtar informationen (db, memcache). Däremot så gör det ofantlig nytta i att minska antalet requests till din applikation.

Med en pull-struktur, liksom den du beskriver, måste varje användare gå till din server och ställa en fråga för varje möjlighet som ska ges för uppdatering.

Med en push-struktur med subscriber-modell ansluter de till din server i början av spelet. Varje gång någon lägger en bricka skickas även det meddelandet in till din push-server (eller om den läser ny brickor t ex var 0.1 sekund). Denna skickar sedan ut meddelandet till de som är registrerade som mottagare (i ditt fall en motståndare) över den redan öppna anslutningen utan att en besökare behöver belasta din server med ett extra request för varje tick i uppdateringen. Den skickar bara vad den behöver skicka, när det ska skickas, bottleneck här ligger i antalet spelare istället för hur snabbt saker ska hända. För en snabb lösning, som jag dock är osäker på hur väl den skalar, titta på socket.io och subscriber model.

1M samtidiga spelande kommer du aldrig klara på en burk, oavsett metod eller kod.Men du har en väldig overhead om du ska låta dina användare pinga en gång i sekunden jämfört med att använda en push-modell.

Du kommer inte lyckas skala till en miljon samtidiga användare utan extern expertis om du inte gör ett rejält djupdyk i skalbarhet och prestanda av liknande applikationer. När man kommer upp i sådana nivåeer är det också viktigt att ha finansieringen klar för sig. Det är därför de flesta stora startups har investerare, inte för att begränsa sin handlingsförmåga.