← Back to Projects
Business Services

User Group & VIP System

Dynamic user segmentation with VIP tiers and agent rebate networks

Backend Engineer · Jul 2024 — Present
Go go-zero gRPC MySQL/GORM Redis Kafka
8
Tables

Background

User group and VIP management service handling tier promotion/demotion, multi-level agent rebate calculations, and dynamic group policies. Must support an infinite-depth agent network with real-time VIP status changes driven by user activity.

Architecture

Kafka events (bet placed, period closed) → go-zero consumers → VIP tier engine (promotion/demotion rules) → MySQL (8 tables) + Redis cached VIP bet IDs. Batch settlement via distributed lock → agent rebate tree traversal.

Key Implementations

1

VIP Tier Auto Promotion/Demotion

Evaluates user activity against configurable tier thresholds and automatically promotes or demotes VIP status on each qualifying event.

Why: Manual VIP management does not scale; automated tier transitions ensure users always see accurate benefits without admin intervention.

2

Infinite-Depth Agent Rebate Network

Traverses an unbounded parent-child agent tree to calculate cascading rebates at each level based on configurable rate policies.

Why: The business model requires multi-level commission distribution where agent structures can grow to arbitrary depth.

3

Batch Settlement with Distributed Locks

Processes rebate settlements in batch jobs protected by Redis distributed locks to prevent duplicate payouts across concurrent executions.

Why: Financial settlement must be exactly-once; distributed locks ensure only one pod processes a given settlement window.

Technical Decisions

Technical Decisions Chosen Alternative Reason
Agent tree traversal Recursive traversal with cached intermediate results Materialized path or closure table Recursive traversal with Redis caching handles infinite depth without the storage overhead of pre-computed paths.
VIP state change trigger Kafka event-driven Polling/cron-based recalculation Event-driven updates reflect VIP changes immediately after qualifying activity rather than waiting for the next cron cycle.