加密赌场

Torrent Gear

事件和奖项自动化：规则和网络指南

游戏化取决于两个"摩托车运动员"：事件（用户所做的事情）和规则（这取决于什么）。为了使它大规模且无误地工作，您需要可靠的事件总线，规则引擎，交付/颁奖机制以及严格的防伪保护。下面是实用体系结构，模板和支票单。

1）流式架构"事件→规则→奖励"

1.Ingest（事件输入）：SDK/Web，来自付费游戏/游戏提供商的服务器网络手册→ Gateway API →队列/总线（Kafka/Rabbit/Cloud Pub/Sub）。

2.Normalizer：验证，富集（geo，device，payer_flag)，电路版本。

3.规则引擎：得分/CV，任务/任务检查，奖励/通知触发器。

4.Reward Orchestrator：计算奖项，预算支票，RG/KYC门，创建"发行任务"，写入日志。

5.Payout/Bonus Service：缓存/奖金缓存/飞盘/优惠券，外部webhooks（钱包，提供商）。

6.Notifier： push/in-app/email/messenger带频率限制。

7.Storage/Analytics：原始事件、店面、A/B、Alerta。

8.Anti-Fraud/RG：帽子，启发式/ML，大奖的保留和审查。

2）事件模型（最小集）

json
{
"event_id": "d9e8-...-5c2",  "event_name": "bet",  "version": "1.2.0",  "ts": "2025-10-24T11:37:21Z",  "user": {
"id": "u_123",   "geo": "TR",   "platform": "android",   "payer_flag": true,   "risk_flags": ["vp_nightly"]
},  "context": {
"session_id": "s_789",   "device_fp": "fp_...",   "ip": "203.0.113.24"
},  "payload": {
"game_id": "slot_wolf",   "bet": 0.5,   "win": 1.25,   "currency": "EUR",   "provider": "GameCo"
}
}

Базовые типы: `login`, `session_start/end`, `bet/spin`, `win`, `deposit`, `withdraw_request`, `kyc_status_changed`, `mission_view/join/progress/complete`, `tournament_join/score/update/reward`, `reward_issued`, `rg_event`.

3）规则引擎： 如何描述逻辑

概念：规则（if/then），细分，时间窗口，帽子，优先级，转化。

声明规则示例（YAML样式）：

yaml rule_id: r_points_winmult_v2 when:
event_name: bet filters:
- payload.bet >= 0.2
- user.geo in ["TR","BR","PE"]
- now between "2025-11-01" and "2025-11-30"
score:
formula: "floor((payload.win / payload.bet) 3)"
caps:
per_bet: 50 per_minute: 200 per_day: 1500 reward_trigger:
on_progress:
threshold: [100, 300, 800]
reward: [{type: "fs", value: 10}, {type: "bonus_cash", value: 2}, {type: "loot", rarity: "rare"}]
guardrails:
kyc_min_level: 2 rg_limits_ok: true budget_pool: "nov_season"
budget_soft_cap: 80000 meta:
version: "2.0"
experiment: "scoring_ab_2025w45"

4） Webhooks： 集成服务器

4.1.出站webhooks（从您到提供商/钱包）

方法： 'POST https：//合作伙伴。example/payouts`

Подпись: `X-Signature: HMAC-SHA256(secret, body)` + `X-Request-Id` (idempotency).

Retrai：指数后端，"max_retries=8"，jitter，DLQ。

Idempotency：重播相同的"X-Request-Id" →合作伙伴必须回答相同的"payout_id/status"。

payload示例：

json
{
"request_id": "rid_7f5...",  "user_id": "u_123",  "reward": {"type":"cash","amount":10.00,"currency":"EUR"},  "reason": "milestone_300_points",  "kyc_level": 2,  "constraints": {"wagering": 0, "expiry_at": "2025-12-01T00:00:00Z"}
}

4.2.传入的webhooks（给你）

仅允许IP/MTLS列表，检查HMAC和签名寿命（"X-Timestamp"，± 5分钟）。

将"原始"body+标题保存到审计存储（WORM）中。

任何双打/重播→检查相对于日志的idempotency键。

5）可靠性： "水平"流动没有双重支付

ingest+idempotent上的at-least-once处理程序→金本位制。

Idempotency key："hash（event_id+user_id+rule_id）"用于计分；颁发"reward_task_id"奖励的单独密钥。

Exactly-once语义仅在逻辑上（通过幂等）是现实的，而不是运输。

事件顺序：存储"event_ts"和"ingest_ts"；从"user_id"键的队列中应用reordering窗口（例如60秒）和replay。

Dead Letter Queue (DLQ):

我们在那里写信时存在永久错误（临时计划未通过，签名不合格，预算已关闭）。

使用reprocess/drop/fix计划按钮的"咆哮DLQ"服务。

6）预算和保证金保护

预算池："nov_season"，"daily_sprint"，"vip_weekend"。

配额：软/硬帽，"巡回赛决胜局"-当预算达到90％时，将大奖转为保留状态。

单一成本："Prize&Bonus Cost per Active/Payor"，Net Uplift。

优先事项：RG和合规性比促销更重要-在冲突中，奖励被推迟。

预算检查示例（SQL草图）：

sql
SELECT pool_id,    SUM(amount) AS spent,    budget AS limit,    SUM(amount)/budget AS fill
FROM reward_ledger
WHERE pool_id =:pool AND date(ts) = current_date
GROUP BY pool_id, budget;

7）RG/KYC/Geo门（玩家安全和合规性）

KYC：缓存/大奖的最低L2；L1允许飞旋。

RG：在取消限制之前，检查存款限额、自我排除、"冷静"→奖励"冻结"。

Geo：每个规则/奖项池的授权国家列表。

阈值变量：个别帐户"几乎达到"的急剧增长=保持和评论的理由。

8）反亲属规则和遥测

每天/分钟/小时/小时的积分帽，最低费率方差，禁止"完美"模式。

Tehsignals：无头，重复device_fp，代理子网。

异常："眼镜/投注"和"眼镜/分钟"是99 percentile上的长"尾巴"。

为顶级奖牌获得者保留和审查：KYC自动支票+手动查看。

9）监视，度量标准和Alerta

SLO/SLA:

Ingest p95 ≤ 250毫秒；处理p95 ≤ 150毫秒规则；领导层更新≤ 2 c；颁发奖项≤ 60秒。

Error budget < 0.每天1％的事件。

Alerts：

实验中的SRM（流量偏斜），DLQ的增长，HMAC验证签名下降，预算超支，单倍激增。

Dashbord（每天）：

事件/s，脱落，容错性；
漏斗：事件→规则→ reward_task → reward_issued；
费用：Prize/Bonus per Active, Net Uplift；
质量：指纹标志，KYC块，RG触发。

10）验证和迁移

每个规则都是versioned（'rules。version`).

如果没有新版本，则无法编辑活动规则；使用ficheflag和"平稳加热"（10% → 50% → 100%）。

通过计划注册的事件模式；不兼容的更改-仅主要版本。

11） A/B自动化测试（简短）

单位-用户；sticky-assignment;分层（payer/geo/platform）。

分开的排行榜或积分正常化以消除干扰。

Primary: participation_net, completion, Net ARPPU;Guardrails：投诉/1k, frod-flags, RG触发。

CUPED和协变量以减少方差。

12）示例： 从规则到引渡

12.1.触发器"微观进步奖"

json
{
"type": "reward_task.created",  "reward_task_id": "rt_456",  "user_id": "u_123",  "origin": {"rule_id":"r_points_winmult_v2","threshold":300},  "reward": {"type": "bonus_cash", "amount": 2, "currency":"EUR", "wagering": 15},  "pool_id": "nov_season",  "status": "pending",  "created_at": "2025-10-24T11:38:30Z"
}

12.2.外出webhook到钱包


POST /wallet/credit
X-Request-Id: rid_7f5...
X-Timestamp: 1730061700
X-Signature: sha256=7b9a...

{ "user_id":"u_123", "amount":2.00, "currency":"EUR", "reason":"rule:r_points_winmult_v2" }

成功→ "reward_task"="succeeded"并写入"reward_ledger"。

失败（5 x/taymaut）→具有相同"X-Request-Id"的后退。

失败（4xx） → DLQ+手动解析。

13）存储和表格（草图）

sql
-奖项杂志
CREATE TABLE reward_ledger (
id BIGSERIAL PRIMARY KEY,  reward_task_id TEXT UNIQUE,  user_id TEXT,  pool_id TEXT,  type TEXT,  value NUMERIC(18,2),  currency TEXT,  cost NUMERIC(18,2) DEFAULT 0, -- реальная стоимость для P&L status TEXT, -- succeeded/failed/held created_at TIMESTAMPTZ,  updated_at TIMESTAMPTZ
);

-不可持续性
CREATE UNIQUE INDEX uniq_reward_task ON reward_ledger (reward_task_id);

-预算
CREATE TABLE reward_budget (
pool_id TEXT PRIMARY KEY,  budget NUMERIC(18,2),  spent NUMERIC(18,2),  period DATE
);

14）安全和隐私

HMAC签名，MTLS，allow-list IP。

过境/静止加密，按键旋转，保管箱中的秘密。

最小化付费中的数据（单独使用PII，通过引用令牌，TTL）。

审核日志不可变（WORM）。

保留和处置策略（遗忘、重复数据消除安全）。

15）发射支票清单

事件图和注册表，webhook合同（签名，TTL）。
队列、转发、DLQ、等效处理程序。
KYC/RG门规则中的帽子/警员。
预算池，电路断路器，溢出变量。
Dashboard SLO+漏斗恢复。
A/B-ficheflagi和SRM监测。
事件运行手册（重播、冻结、手动发行）。

16）迷你桉例（合成）

游戏和钱包提供商的活动已连接；包括带有帽子的"win/bet"得分。

Webhooks由HMAC签名，最多可进行8次尝试，DLQ每2小时进行一次咆哮。

在4周内： p95 180毫秒的处理时间；DLQ < 0,06%;付款0；前旗− 0.4个百分点；ΔParticipation_net +6,3 п.п.;ΔARPPU (net) +€2,1 при Prize&Bonus/Active +€0,7.

结论：将规则扩展到具有本地预算池的新地理位置。

颁奖自动化不是"随心所欲地发送"。这是一个工程系统：可靠的事件交付，严格的规则验证，idempotency和签名，预算私人，KYC/RG门，防冻和监视。有一天建造这个框架-任何任务，锦标赛和"战利品时刻"都可以预见，及时且具有积极的净效果。