Əməliyyat və oyun nəticələrinin önbelləklənməsi: yanaşmalar və risklər

1) Niyə önbelleğe almaq lazımdır və harada lazımdır

Cache - gecikmə və nüvə yükünü azaltmaq üçün bir vasitədir. iGaming-də bu vacibdir:

Balans və əməliyyat statuslarının oxunması (tez-tez GET sorğuları);
Oyunların/spinlərin və aqreqatların hekayələri (Liderbord zirvələri, son N nəticələri);
Oyunların/provayderlərin meta məlumatları, bahis limitləri, statik kataloqlar;
UX (banner, promo status) üçün FID əmsalları və «sürətli» arayışlar.

Lakin cache heç vaxt pul və nəticələr üçün həqiqət mənbəyi deyil. Həqiqət ledger/cüzdan və provayderdən təsdiqlənmiş nəticələrdir.

2) Qırmızı xətt: nəyi keşləşdirmək olmaz

Pul qeydiyyatı: balansın silinməsi/hesablanması (qeyd əməliyyatları) - yalnız əməliyyatlar və idempotentlik ilə DB/ledger vasitəsilə.

Provayder tərəfindən təsdiqlənməmişdən əvvəl bahis/uduşla bağlı qərarlar.

KYC/AML və ödənişlərə təsir edən uyğunluq bayraqları.

Sirlər/tokenlər (prosesin yaddaşında cache, lakin ümumi cache deyil).

3) Əsas caching nümunələri

Cache-aside (lazy): tətbiq ilk olaraq keş axtarır, səhv olduqda - DB-dən oxuyur və cache-də yerləşdirir ('get → miss → load → set'). Universal və oxumaq üçün təhlükəsiz.

Write-through: DB-də qeyd cache vasitəsilə keçir; açarın aktuallığını təmin edir, lakin yazının gecikməsini artırır.

Write-behind (write-back): qeyd əvvəl cache, sonra asenxron DB. Pul/nəticələr üçün qadağandır - düşmə zamanı itki riski.

Read-through: Cache özü DB-dən necə alınacağını bilir (məsələn, Redis with modules/sidecar). Metadata üçün yaxşıdır.

Tövsiyə: oxumaq üçün cache-aside, write-through yalnız təhlükəsiz olduğu yerdə, write-behind - pul/oyun həqiqətləri üçün heç vaxt.

4) Tutarlılıq və idempotentlik

Həqiqət mənbəyi: ledger (append-only), 'operation _ id' və idempotent emalı ilə əməliyyatlar.

Balans: cashdan oxuyuruq, lakin kritik hərəkətlərdən əvvəl bazadan hər hansı bir uyğunsuzluğu təsdiqləyirik (depozit/çıxarış/böyük bahis).

Əlillik: DB → del/expire müvafiq balans/status açarlarının uğurlu qeydiyyatı ilə.

Duplication: outbox/inbox + idempotency keys webhook/ödənişlər üçün; keş dedupda iştirak etmir, yalnız oxumağı sürətləndirir.

5) TTL, əlillik və «köhnəlmə hüququ»

Balans üçün qısa-TTL: 1-5 saniyə (və ya background refresh ilə yumşaq-TTL).

Əməliyyatların statusları: hadisələr üzrə aktiv əlilliyi olan qısa TTL (5-30 s) ('deposit _ completed', 'settled').

Oyun tarixi: TTL 1-10 dəqiqə, 'new _ round' hadisəsinə görə əlillik.

Metadata/referanslar: TTL 10-60 dəqiqə, deployda warm-up.

Event-driven əlilliyi: şin hadisələri (Kafka/PubSub) dərc edir 'wallet _ updated', 'bet _ settled', 'bonus _ changed' → abunəçilər silinir/açarları yeniləyin.

6) Antishtorm nümunələri (fırtına qaçırma və doqon)

Request coalescing: bir axın sorğunu bazaya «aparır», qalanları gözləyir (mutex per key).

Stale-while-revalidate: «bir az köhnəlmiş» veririk, eyni zamanda fonda yeniləyirik.

TTL üçün Jitter: TTL-i (± 20%) randomize edin ki, açarlar eyni vaxtda tükənməsin.

Qaçırma arxası: daimi qaçırmalar/səhvlər - müvəqqəti negative-cache (aşağıya bax).

7) Negative-caching və boz kardinal səhvlər

«Tapılmadı» (məsələn, hələ əməliyyat statusu yoxdur) - 1-3 s qısa negative TTL.

Bir neçə saniyədən çox DB/provayder səhvlərini önizləməyin - əks halda qəzanı düzəldin.

Müşahidə üçün canary açarlarını daxil edin: mənfi hitlərin payının artması alert üçün bir səbəbdir.

8) Açar strukturu və seqmentasiya

Именование: `wallet:{userId}`, `txn:{txnId}:status`, `game:{provider}:{tableId}:last_results`, `leaderboard:{tournamentId}:top100`.

env/region/brand üzrə seqmentlər/neyspeyslər: 'prod: eu: wallet: {userId}' - kəsişmələri və xaç-regional zibilləri istisna edin.

Kardinallığı məhdudlaşdırın - xüsusilə liderbordlar və tarix üçün.

9) edge, klasterdə və yaddaşda cache

Edge Cache (CDN/WAF): yalnız qeyri-personal məlumatlar üçün (oyun metadata, ictimai liderbordlar, media). Sorğu parametrləri - whitelist; cache-busting qarşı müdafiə.

Redis/Memcached (klaster): fərdi oxunmalar üçün əsas; AOF/RDB snapshotlar, replikalar və kvotaları daxil edin.

In-process cache: qaynar kataloqlar üçün mikrosaniyə giriş; əlillik mexanizmləri tələb olunur (broadcast, version key).

10) Pul halları: təhlükəsiz sürətləndirmə

Oyunçu balansı

Oxu: TTL ilə cache-aside 1-5 s.

Qeyd: balans cache DB → del əməliyyat; kritik təsir (çıxış/böyük bahis) - «recheck from DB».

Antigone: optimistic balans locking versiyası.

Ödəniş statusu

Ssenari: istifadəçi «status yenilənir».

Həll: «pending «/» unknown »2-5 s cache-aside + negative TTL; PSP → əlillik vebhuk yeniləmə.

Bonuslar/Veyger

Aqreqatlar (% -də irəliləyiş): 10-30 saniyəni keçmək; hadisə üzrə əlillik 'bet _ placed/settled'.

11) Oyun halları: həqiqəti təhrif etmədən sürətli cəbhə

Spin/bahis tarixi

Son N hadisələri: limitli cache siyahısı (məsələn, 100), TTL 1-10 dəq, 'round _ finished' hadisəsi ilə doldurma.

Provayderdən təsdiq olmadıqda «uduşlar» göstərilə bilməz → «pending» aralıq statusu.

Canlı oyunlar (WebSocket)

Tez qoşulan müştərilər üçün 1-3 saniyədə ən son mesajların/masa vəziyyətinin qısamüddətli keşi.

State açarlarını 'tableId/market' ilə parçalayın.

Liderbordlar

Precompute + 10-60 saniyədə cache; kütləvi yeniləmələr üçün - batch yeniləmələri və «pəncərələrin» qismən əlilliyi.

12) Risklər və onları necə bağlamaq olar

Cüt silinmə/Fantom uduşları: yalnız cache-dən oxumaq; bütün silinmələr/hesablaşmalar - DB və idempotentlik vasitəsilə.

Köhnə məlumat → oyunçu ilə mübahisə: qısa TTL, ödəniş əvvəl «ciddi reallıq», şəffaf statuslar («təsdiq gözləyir»).

Split Brain Cash Cluster: kvorum/sentinel, timeouts, write-behind imtina.

Cache stampede: coalescing, jitter, stale-while-revalidate.

Cache-injection/poisoning: ciddi açarlar, cached API cavabları üçün işarələr/imza, kanarya yoxlamalar.

Gizlilik/PII: kanalın şifrələnməsi (mTLS), şəxsi məlumatlar üçün edge cache qadağası, qısa TTL, giriş zamanı təmizləmə.

13) Keşin müşahidə edilməsi

Hər təbəqə üçün metriklər:

Açar kateqoriyalarına görə Hit/Miss ratio; redis_ops/sec, latency p95/p99, evictions, memory_usage.
Kanarya açarları: 'cache _ health: {segment}' - negative-cache payının və yeniləmə vaxtının yoxlanılması.
Log: «paket», tez-tez 'del' bir seqment = «səs-küylü» xidmət əlaməti.
Traces: açar etiketləri olan «cache get/set/del» spanları (PII olmadan).

14) Mini memarlıq (istinad)

1. App (API/WS) → Redis-klaster (TLS, auth).

2. Həqiqətin mənbəyi: Wallet DB (ledger), Game results store.

3. Hadisə şini: 'wallet _ updated', 'bet _ settled', 'promo _ changed'.

4. Əlil: hadisələrə abunəçi → 'del '/' set' isti açarlar.

5. Edge Cache: Yalnız ictimai resurslar/lider bordları.

6. Müşahidə: keş daşbordları, stampede, mənfi hitlər.

15) TTL siyasətləri (təxmini matris)

Kateqoriya	Açar nümunəsi	TTL	Hadisə üzrə əlillik
Balans	`wallet:{user}`	1-5 s	`wallet_updated`
Əməliyyat statusu	`txn:{id}:status`	5-30 s	`deposit_completed/failed`
Spin tarixi	`game:{table}:last_results`	1-10 dəqiqə	`round_finished`
Liderbord	`leaderboard:{tour}:top100`	10-60 s	'score _ updated' (qismən)
Oyun metadata	`game:meta:{provider}`	10-60 dəqiqə	deploy/refresh
Promo statusları	`promo:{id}:status`	10-30 s	`promo_changed`

16) Təxmini psevdokod (balansın təhlükəsiz oxunması)

python def get_balance(user_id):
key = f"wallet:{user_id}"
bal = cache. get(key)
if bal is not None:
return bal səhv: BD-dən götürün və qısa TTL + jitter bal = db ilə qoyun. get_wallet_balance(user_id)
cache. set(key, bal, ttl=randint(1,5))
return bal

def apply_transaction(op_id, user_id, delta):
if db idempotentliyi ilə DB-də atom qeydiyyatı. exists_op(op_id):
return db. get_result(op_id)
res = db. apply_ledger (op_id, user_id, delta) # əməliyyat cache. delete (f «wallet: {user _ id}») # əlillik return res

17) Production-hazırlıq yoxlama siyahısı

Aydın sərhəd: DB həqiqət, cache - yalnız oxumaq üçün.
Nümunələr: oxumaq üçün cache-aside; write-behind qadağandır.
Hadisə əlilliyi: 'wallet _ updated', 'bet _ settled', 'promo _ changed'.
Qısa TTL + jitter; negative-cache ≤ 3 с.
Antishtorm: coalescing, stale-while-revalidate.
env/region/brand üçün açarların seqmentləşdirilməsi; kardinallıq limiti.
Müşahidə: hit/miss, evictions, p95, stampede alertlər/negative-spikes.
Edge-cache yalnız ictimai məlumatlar üçün; fərdi - yalnız Redis/TLS.
Runbook: Russinchron ilə nə etmək (forced refresh, seqment cache müvəqqəti bağlanması).
Müntəzəm testlər: qaynar açarları yük, stampede təlimləri.

Xülasə

iGaming-dəki önbellək «pul üçün ikinci məlumat bazası» deyil, oxu sürətləndiricisidir. Həqiqəti ledger-də saxlayın, idempotentliyi və hadisə əlilliyini təmin edin, qısa TTL və antiştorm mexanikasını saxlayın, edge-keşi və şəxsi məlumatları paylaşın, cache metrlərinə nəzarət edin. Beləliklə, «qazanma illüziyaları», ikiqat silinmələr və tənzimləmə problemləri olmadan sürətli UX alacaqsınız.