Turniej i moduł misji: Wydarzenia, oceny, nagrody

1) Cele biznesowe i rodzaje działalności

Cele: Utrzymać wzrost (D1/D7), ARPPU, zwiększyć głębokość sesji, promować nowe gry i rynki.

Formaty:

Turnieje: przez ilość punktów/wygranych/mnożników, sprinty (30-60 minut), dzienne, sezonowe.
Misje/zadania: sekwencje zadań (graj w N spiny, wygraj X, spróbuj Y dostawca), z postępu i nagrody sceniczne.
Liderboards: global, by markets/games/bets, private (friends/VIP).
Oceny jackpotów/studio: „najlepsi dostawcy tygodnia”, „polowanie na mnożnik”.

KPI: udział ≥ 12-25% aktywnej publiczności, udział dochodu z promo 10-20%, skargi <0. 5% uczestników, pula nagród ≤ wydany plan.

2) Architektura i przepływy danych

Komponenty

1. Wydarzenia Gateway → odbiór wydarzeń gry (spin, bet, win, round_end) od gry-gateway/dostawców.

2. Zasady Silnik → dopasowuje wydarzenia na zasadach turniejów/misji, punktów nagród (idempotent).

3. Liderboard Service → agreguje punkty, przechowuje blaty/plasterki, obsługuje sortowanie i tie-breaks.

4. Progress Service (misje) → status zadań/etapów, wydawanie nagród tymczasowych.

5. Usługa nagród → rozliczenie i bezpieczna płatność (poprzez portfel: gotówka/bonus/fs/punkty).

6. Administrator/Studio UI → tworzenie, planowanie, podgląd gospodarki, symulacje.

7. Czas rzeczywisty/WS → publikacja aktualizacji tablicy przywództwa, postępy, powiadomienia.

8. Anty-Abuse → limity, sygnały ryzyka, integracja z anty-fraud/bot manager.

9. Pamięć masowa/pamięć podręczna → KV/Redis na gorące blaty, OLTP na fakty, DWH na analitykę.

Strumień (e2e)

'gra _ event → gateway → rules_match → punkty → leaderboard_update → (progress_update) → powiadom → rewards_at_close → wallet_postings'

3) Model zdarzenia (minimalne pola)

json
{
„event_id":” e_9f2, „” ts': „2025-10-23T17:41:26Z,” „user_id":” u_123, „” rynek „:” DE „,” marka „:” X „,” gra „: {” id': „g _ 77”, „dostawca”: „PragmاPlay”, „typ”: „slot”}, „zakład”: {„amount _ minor”: 100 „, waluta”: „EUR”}, „win”: {„amount _ minor”: 250, „mnożnik”: 2. 5}, "round": {"id':" r _ abc', "status": "ended"}, "device": {"platform": "mobile", "asn": "mno"}, "trace_id":" t_... "
}

Transport - Kafka/HTTP, idempotent processing (dedupe by 'event _ id'), dostawca/game gateway signature (HMAC).

4) Zasady turnieju i projektant zadań

System deklaracji (przykład YAML):

yaml id: t_october_sprint okno: {start: 2025-10-25T18:00Z, end: 2025-10-25T19:00Z, tz: Europe/Kyiv}
zakres:
rynki: [DE, SE]
dostawcy: [PragmاPlay, Hacksaw]
punktacja:
wzór: "punkty = min (wygrana. kwota/zakład. kwota, 50) 100” # pomnożone przez min_bet_minor: 50 eligible_games: [„g _"]
liderboard:
typ: "best_n_rounds" # podsumować najlepsze rundy N n: 20 tiebreaker: ["highest _ single _ multiplier", "earliest _ finish _ ts']
nagrody:
pula: {waluta: EUR, total_minor: 1000000}
dystrybucja: drabina # drabina, top 100 anti_abuse:
min_round_duration_ms: 800 max_rps_per_user: 0. 5 exclude_asn_categories: [„hosting”, „proxy”]

Misje (DSL):

yaml mission_id: m_halloween kroki:
- id: s1 goal: {type: „spin_count,” game_type: „slot”, count: 50}
nagroda: {typ: "freespins", wartość: 10, gra: "g_66"}
- id: s2 goal: {type: „win_multiplier,” min: 10}
nagroda: {typ: „bonus”, amount_minor: 500}
completion_reward: {typ: „punkty”, kwota: 1000}

5) Ratingi i algorytmy obliczeniowe

Główne modele

Punkty całkowite: liniowy/logarytmiczny/z nasadką na rundę.

Najlepsze rundy N: obniża pay-to-grind, utrzymuje pęd sprintu.

Maksymalny mnożnik (xWin): normalizuje waluty i kursy.

System MMR/rating: Podobny do PvP/przyjaznych stołów konkurencji.

Zerwania wiązania

1. 'highest _ single _ multiplier' → 2) 'fewest _ rounds' → 3) 'earliest _ finish _ ts' → 4)' user _ id' leksykograficznie (ustalone w zasadach).

Wydajność

Zapisz górną część K (na przykład 10k) w Redis Sorted Set 'ZADD key score member'.

Dla „najlepszych rund N”: zachować min-hałas najnowszego najlepszego N na użytkownika i ilość, zaktualizować na muchę.

Okresowo migawka (co 30-60 s) w OLTP/obiekcie.

6) Nagrody i płatności

Rodzaje nagród: gotówka/bonus/darmowe spiny/punkty/przedmioty/bilety.

Zasady:

Wydanie tylko po zakończeniu (okno odwoławcze 5-10 minut).
Wszystkie płatności są za pośrednictwem Usługi Rewards → Portfel (księga): podwójny wpis, idempotencja przez 'reward _ id'.
W przypadku pośrednich etapów misji - emisja nagród „miękkich” (FS/punkty), gotówka - na koniec łańcucha.
CCM/odpowiedzialna gra: podczas blokowania konta, wstrzymać/zamrozić nagrodę do czasu weryfikacji.

Systemy dystrybucji:

Drabina stała: wstępnie zdefiniowane kroki (1. miejsce 30%, 2. 20%,...).
Proporcjonalny: część puli w punktach, ale z nasadką na miejscu.
Bilety: Misje dają „bilety”, czerpiąc z biletów (przezroczysty RNG).

7) Przeciwdziałanie nadużyciom, uczciwość i zgodność

Filtry kwalifikowalności: min zakład/okrągły czas trwania, wyłączenie "0-bet', powtórne pęknięcia," mikro zakłady "w rurociągu.

Sygnały bot: bezgłowa-UA, nienormalna częstotliwość, nienormalnie stabilny RPS, proxy ASN → ukryte wyzwania/okulary zamrażania.

Dedup/idempotence: zdarzenia według 'event _ id', memoriały przez' score _ id'.

Ścieżka audytu: strzały liderów, RNG nasion (do losowania biletów), wersja reguły, hash obliczeń.

Przepisy prawne: przepisy/ograniczenia dotyczące rynków, wieku, samodzielnego wykluczenia.

8) Ekonomia turnieju

Bariery budżetowe: górna granica puli + dynamiczny „zawór bezpieczeństwa” (zmniejszenie premii pośrednich przy przegrzaniu).

Elastyczność: Przesuwanie nagród na punkty/FS zamiast gotówki, aby utrzymać marżę.

Współczynniki zwrotu: pula nagród/wpływy z segmentu gier turniejowych; cel 8-15%.

Symulator w panelu administracyjnym: przebieg wydarzeń historycznych → prognoza płatności/udziału.

9) Umowy API (uproszczone)

Pobierz aktywne turnieje/misje

http
DOSTAĆ/v1/konkursy? rynek = DE & marka = X
→ 200 [{"id':" t _ october _ sprint "," start ":"... "," end ":"... "," type ":" xwin "," status ":" live "}]

Gra Event (ingest)

http
POST/v1/wydarzenia
{"event _ id':" e _ 9f2 ","... ":"... "}
→ 202 {„przyjęte”: true}

Lider (top K i pozycja użytkownika)

http
GET/ v1/leaderboards/t_october_sprint? top = 100 & me = u _ 123
→ 200 {„top”: [{„pos': 1,” user „:” u _ 9 „,” score „: 18400},...],” me „: {” pos': 342, „score”: 5600, „delta”: + 200}}

Postępy misji i nagroda

http
GET/ v1/missions/m_halloween/progress? użytkownik = u _ 123
→ 200 {„kroki”: [{„id':” s1 „,” done „: true}, {” id': „s2”, „done”: false}], „reward _ ready”: true}

POST/v1/nagrody/roszczenie
{"kontekst": "misja", "id':" m _ halloween "," krok ":" s1 "}
→ 201 {"status": "granted", "reward _ id':" rw _ 77 "}

10) Przechowywanie i skalowanie

Gorący sposób: Redis (sortowane zestawy/Hash) dla blatów i postępu; TTL dla „hałaśliwych” kluczy, shading by 'contest _ id'.

Prawda: OLTP (Postgres/MySQL) - punkty/postępy/fakty wypłat (migawki WORM).

Kolejki: Kafka - przepływ wydarzeń; Grupy konsumentów według regionu/marki.

Caches: krótki TTL 1-5 s; stale-while-revalidate dla wierzchołków publicznych (poprzez CDN).

WebSocket: oddzielny klaster/pula dla czasu rzeczywistego, wysyłki serii i wiadomości limitu stawki.

11) Obserwowalność i kontrola jakości

SLI/SLO:

„leaderboard _ update _ latency _ p95 ≤ 250с”
'events _ ingest _ success ≥ 99. 9%`
"rewards _ grant _ success ≥ 99. 9%`
„ws _ push _ rtt _ p95 ≤ 120мс”
reklamacje niesprawiedliwości <0. 5% uczestników.

Metryka:

wskaźnik zdarzeń/uczestników, unikalnych graczy, rozkład według zakładów/gier, średni mnożnik; 'grant _ errors',' dedupe _ hits '.
Trasy: ingest → zasady → wynik → aktualizacja LB → nagroda; 'contest _ id',' rule _ id' tagi.
Kłody: JSON z 'trace _ id', zakaz PII; WORM do audytu.

12) Incydenty i runbook "oraz (skrócone)

A. Lider board lag (lag> 2s)

Działania: zwiększenie konsumentów Kafka, zmniejszenie partii „gorący klucz” (rozkład), umożliwienie aktualizacji partii.

Tymczasowe: zamrozić animacje w czasie rzeczywistym, pokaż „~ 1-2s opóźnienie”.

B. Błędy w nagrodach

Działania: zatrzymać nowe „grant”, sprawdzić za pomocą migawki, powtórzyć „grant” idempotently; aktualizacja stanu w holu.

C. Skok nadużyć (pełnomocnik ASN)

Działania: zwiększenie kwalifikowalności, umożliwienie niewidzialnego wyzwania, tymczasowe zignorowanie punktów do wątpliwych sesji, po weryfikacji.

13) UX i lokalizacja

Czas rzeczywisty: wskaźnik „live”, gładkie delty punktów, położenie i odległość do następnego miejsca.

Przejrzyste zasady: dostęp do formuły/tiebreakerów/ograniczeń.

Powiadomienia: „5 minut w lewo”, „jesteś w pierwszej 50”, „nagroda jest dostępna”.

Lokalizacja/teksty prawne: według rynku, stref czasowych (Europa/Kijów i lokalizacje uczestników).

14) Bezpieczeństwo i prywatność

Pseudonimy gracza na publicznych szczytach; Domyślnie ukryj PII.

Podpisy haków/wydarzeń, mTLS; ochrona przed „trucizną cache” na krawędzi.

API limit, zabezpieczenie pamięci podręcznej, kontrola „idempotence _ key”.

RODO: zachowanie zdarzeń, prawo do usunięcia (anonimizacji) bez uszkodzenia audytu.

15) Badania i symulacje

Powtórka wydarzeń historycznych do walidacji zasad i ekonomii.

Obciążenie: pęka 30-120 s przed startem; moczyć 2-4 godziny.

Nieruchomości: niezmienne („kwota wyemitowanych nagród ≤ budżet”, „tie-break determined”).

A/B: różne formuły punktacji, głębokość drabiny, format misji.

16) Lista kontrolna gotowości do produkcji

Zasady deklaracyjne (wersje, podpisy), symulator ekonomiczny.
Idempotencja: 'event _ id',' score _ id', 'reward _ id'; Skrzynka odbiorcza/skrzynka odbiorcza.
Przerwy w krawacie są ustalane w przepisach, sortując determinizm.
Lidery: top K w Redis + migawki; anty-burza (jitter, koalescing).
Przeciwdziałanie nadużyciom: kwalifikowalność, boty/ASN, ograniczenia prędkości.
Nagrody → Portfel poprzez podwójne wejście; Sprawdź KYC przed gotówką.
Obserwowalność: SLI/SLO, deski rozdzielcze, wpisy; Audyt WORM.
DR/Failover: multi-AZ, backups/restore, „freeze & finalize” script.
Lokalizacja, licencje, przepisy publiczne i zgoda.
Runbook "i na lag/errors grant/burst bots, wzorce komunikacji.

Wznów streszczenie

Udanym modułem turniejów i misji jest autobus imprezowy + zasady deterministyczne + szybkie tablice liderów + bezpieczne wypłaty. Dodaj ścisłe tiebreaks, anty-nadużycia, symulator ekonomii i obserwowalność SLO, zachować wszystkie operacje idempotent i auditable - a otrzymasz narzędzie, które rośnie zaangażowanie i przychody bez kłótni z graczami, regulatorami i zespołem wsparcia.