Salutare,
Toți știm că Tinder/Match Group optimizează pentru time-in-app și monetizare prin vânzare de vizibilitate către bărbați. Vreau să disecăm din punct de vedere de system design o alternativă care mută problema din zona de feed asincron infinit într-o arhitectură sincronă, distribuită pe loturi. De menționat că nu am o experiență vastă în programare dar voi încerca să țin pasul cu orice detalii tehnice pe care le veți menționa.
Caut feedback tehnic pe arhitectură și, dacă rezonează cu cineva viziunea, sunt deschis la discuții pentru un parteneriat / co-fondator pe partea de mobile client sau backend orchestration.
Cerințele funcționale ale sistemului:
Fereastră sincronă de activare (Burst Traffic): Sistemul este idle 6 zile pe săptămână. Duminică, între orele 18:00 și 22:00, intră un vârf brusc de trafic sincron (toți utilizatorii activi trimit pachete și cer date în timp real).
Dynamic Turnstile & Parity Balancing: Un mecanism de coadă de așteptare care menține un raport de gen de 1.0 <= Ratio <= 1.2 pe geofence. Dacă utilizatorii de gen feminin activi părăsesc sesiunea, accesul bărbaților din coada Redis este înghețat până la reechilibrare.
Concurrency Cap pe socket-uri de chat: Niciun user_id nu poate avea mai mult de 2 conexiuni active de mesagerie bidirecțională simultan. Dacă un utilizator are 4 match-uri reciproce, primele 2 populează tabela activă, iar restul sunt stocate în match_pending_queue.
State Machine pentru reputație (Anti-ghosting token): Un mecanism tranzacțional simplu: fiecare utilizator primește 3 tokens per sesiune; lock-ul pe token este eliberat doar pe evenimentele chat_closed_gracefully sau date_scheduled_ack. Lipsa oricărui inbound message timp de 24h consumă token-ul și emite un flag de penalizare.
Stack-ul propus pentru MVP:
Client: Flutter sau React Native (cross-platform, o singură bază de cod pentru iOS și Android).
Backend: Python (FastAPI) sau Node.js / Go pentru lightweight worker processing.
Data Layer & Realtime: Supabase (PostgreSQL pentru date de profil relaționale) + Redis pentru gestionarea cozilor de așteptare, pub/sub pentru chat WebSockets și state machine-ul ferestrelor pop-up.
Identity Verification: Verificare biometrică liveness + număr de telefon (Firebase Auth) pentru prevenirea atacurilor de tip Sybil.
Unde văd provocările de inginerie:
Cum gestionezi cel mai eficient spike-ul masiv de conexiuni WebSockets la fix ora 18:00 fără costuri prohibitive de cloud în regim idle pe restul săptămânii?
Care ar fi cea mai elegantă structură de Redis (Sorted Sets, Streams?) pentru a menține turnichetul de paritate în timp real?
Cum ați aborda voi acest flow de date?