برای ارائه عملکرد بلادرنگ پایدار و مقیاس‌پذیر در یک مارکت‌پلیس بازی به سه لایه نیاز دارید: ۱) گِیت‌وی وب‌سوکت/Realtime (اتصال کاربر)، ۲) لایه‌ی پیغام‌رسانی (pub/sub با تضمین تحویل مناسب)، ۳) لایه‌ی پردازش/ذخیره‌سازی (لاگ‌ها، تاریخچه چت، وضعیت سفارش). ترکیب Redis (pub/sub یا streams)، صف پیام (Kafka/RabbitMQ) برای تضمین و Elastic/DB برای لاگینگ معمول‌ترین انتخاب است. در ادامه معماری‌ها، trade-offها و نمونه‌کد FastAPI + Redis آورده شده است.

چرا ویژگی‌های بلادرنگ مهم‌اند؟

• اعتماد و تجربه کاربری: پیام سریع، نوتیف واقعی و آپدیت سریع سفارش‌ها باعث افزایش نرخ تبدیل و کاهش اختلاف می‌شود.

• تعامل بیشتر: چت و نوتیف در لحظه یعنی کاربر بیشتر می‌ماند و احتمال معامله افزایش می‌یابد.

• انتقال وضعیت سفارش: وقتی وضعیت سفارش (پرداخت، تحویل، تأیید) بلادرنگ منتقل شود، فرایند escrow روان‌تر می‌شود.

اصول معماری (High-level)

1. WebSocket / Gateway layer

   • مسئول نگه داشتن اتصالات کاربر، احراز هویت اتصال و توزیع پیام به کلاینت‌ها.

   • می‌تواند با Load Balancer و sticky-session یا با token-based routing کار کند.

2. Message Bus / PubSub

   • Redis Pub/Sub یا Redis Streams برای ارسال فوری پیام‌ها بین سرورها.

   • Kafka یا RabbitMQ برای سناریوهای نیازمند پردازش با تضمین (at-least-once، replay).

3. Processing / Business Logic

   • Workerها پیام‌ها را پردازش، اعتبارسنجی و در صورت لزوم به DB یا سرویس ثالث می‌فرستند (مثلاً ارسال ایمیل یا push).

4. Persistence

   • PostgreSQL برای وضعیت سفارش و تراکنش‌ها.

   • ElasticSearch یا ClickHouse برای جستجوی پیام/لاگ و تحلیل.

   • Redis برای presence / cache و پیام‌های موقت.

5. Push Notifications (APNs/FCM)

   • برای کاربرهای آفلاین پیام از طریق FCM/APNs ارسال شود.

6. Observability & SRE

   • Metrics (Prometheus), Traces (Jaeger), Logs (ELK) و alerting برای SLO و SLA.

الگوهای عملی (Patterns & Trade-offs)

A — ساده و سریع: Single Redis Pub/Sub + stateful websocket servers

• مزایا: پیاده‌سازی سریع، کم‌هزینه.

• معایب: هیچ تضمین تحویلی یا persistence؛ اگر سرور می‌افتد پیام از بین می‌رود. مناسب برای پیام‌های UI/non-critical.

B — Redis Streams + consumer groups (recommended middle)

• مزایا: replay، durability در سطح Redis، consumer group برای پردازش موازی.

• معایب: نیاز به مانیتورینگ stream length و retention.

C — Kafka + durable processors (enterprise grade)

• مزایا: مقیاس‌پذیری بالا، retention و replay قوی، اکوسیستم پردازشی (ksql, stream).

• معایب: پیچیدگی و هزینه بیشتر.

Presence / Online status

• نگهداری presence در Redis (مثلاً key presence:user:{id} با TTL) و انتشار تغییر در کانال presence.

Rate limiting & Anti-abuse

• نرخ‌محدودیت به‌دو شکل: at-connection (per-socket) و per-user (global across sockets). از leaky-bucket یا token-bucket در Redis استفاده کن.

نمونه جریان پیام سفارش (Order update flow)

1. کاربر A عملیاتی انجام می‌دهد (مثلاً mark "delivered").

2. سرویس API وضعیت را در Postgres ذخیره می‌کند و یک event به Kafka/Redis stream منتشر می‌کند: order.updated.

3. workerها event را consume و به channel مربوطه publish می‌کنند (مثلاً order:{order_id}:channel).

4. gatewayهای وب‌سوکت که به آن channel مشترکند پیام را به کلاینت‌های متصل فوروارد می‌کنند.

5. اگر کاربر آفلاین باشد، worker فوروارد به push provider (FCM/APNs) را انجام می‌دهد.

نمونه‌کد: FastAPI WebSocket + Redis Pub/Sub (پایه — async)

این snippet برای فهم جریان است. برای production مواردی مثل reconnect/backpressure و error handling باید کامل شود.

# requirements: fastapi, uvicorn, aioredis, python-jose (برای JWT)
from fastapi import FastAPI, WebSocket, WebSocketDisconnect, Depends
import aioredis
import asyncio
import os
from jose import jwt

app = FastAPI()
REDIS_URL = os.getenv("REDIS_URL", "redis://localhost:6379")
redis = None

async def get_redis():
    global redis
    if not redis:
        redis = await aioredis.create_redis_pool(REDIS_URL)
    return redis

# Simple in-memory registry of connections per user (for demo)
CONNECTIONS = {}  # user_id -> set of websockets

async def verify_token(token: str):
    # ساده‌شده: در عمل از public key / jwks استفاده کنید
    try:
        payload = jwt.decode(token, "secret-key", algorithms=["HS256"])
        return payload.get("sub")
    except Exception:
        return None

@app.on_event("startup")
async def startup():
    await get_redis()
    # spawn background listener
    asyncio.create_task(redis_listener())

async def redis_listener():
    r = await get_redis()
    pubsub = (await r.subscribe("orders", "chat"))  # کانال‌های نمونه
    channels = [c for c in pubsub]
    while True:
        for ch in channels:
            msg = await ch.get(encoding="utf-8")
            if msg:
                # msg expected format: "channel|user_id|payload"
                # مثال: "order:123|user:45|{\"type\":\"order.update\",...}"
                try:
                    target_channel, user_id, payload = msg.split("|", 2)
                except:
                    continue
                conns = CONNECTIONS.get(user_id, set())
                for ws in list(conns):
                    try:
                        await ws.send_text(payload)
                    except:
                        # cleanup broken connections
                        conns.remove(ws)

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket, token: str = ""):
    await websocket.accept()
    user_id = await verify_token(token)
    if not user_id:
        await websocket.close(code=4001)
        return
    CONNECTIONS.setdefault(user_id, set()).add(websocket)
    try:
        while True:
            data = await websocket.receive_text()
            # پیام از کلاینت -> منتشر کن در Redis تا سایر سرورها دریافت کنند
            r = await get_redis()
            # نمونه قالب: "chat|user:45|{\"text\":\"hello\"}"
            await r.publish("chat", f"chat|{user_id}|{data}")
    except WebSocketDisconnect:
        CONNECTIONS[user_id].remove(websocket)

نکات:

• این مثال برای demo است؛ در production از connection pool بیشتر، مدیریت خطا، محدودیت اندازه پیام و اعتبارسنجی پیام‌ها استفاده کنید.

• برای مقیاس‌پذیری CONNECTIONS نباید در حافظه‌ی پروسس نگه داشته شود؛ باید هر گِیت‌وی فقط کانکشن‌های متصل خودش را مدیریت کند و پیام‌ها از طریق Redis/Kafka بین گِیت‌وی‌ها فوروارد شوند.

نکات مهم عملی برای Production

1. Sticky session یا token routing

   • اگر از stateful websocket servers استفاده می‌کنی، برای کاهش راندربک نیاز به sticky sessions (LB) یا یک 토큰 routing که کاربر را به سرور مشخصی وصل کند لازم است. گزینه‌ی بهتر: هر گِیت‌وی اتصال را نگه‌دارد و پیام‌ها را از pub/sub دریافت کند.

2. Backpressure و batching

   • از فشرده‌سازی (gzip) و batching پیام استفاده کن. برای کاربران با شبکه ضعیف پیام‌ها را با QoS پایین‌تر ارسال کن یا drop کن.

3. QoS و تضمین تحویل

   • برای پیام‌های حساس (مثلاً وضعیت مالی) از Kafka/Streams با acknowledgement استفاده کن. پیام‌های UI-only می‌توانند best-effort باشند.

4. Security

   • WebSocket باید TLS داشته باشد (wss). JWT باید کوتاه‌مدت و دارای claim مناسب باشد. از CORS/Origin checks استفاده کن، و limit rate برای جلوگیری از DoS.

5. Persistence و audit

   • هر رویداد مهم (order state change, dispute events) را لاگ و ذخیره کن تا در حل اختلاف به کار آید.

6. Monitoring

   • Metricهایی مثل connections, messages/sec, avg-latency, redis-stream-lag و consumer-lag باید پایش شوند.

KPIهایی که باید پایش کنید

• تعداد کانکشن همزمان (peak)

• میانگین latency پیام (publish → delivery)

• پیام‌های از دست‌رفته یا failed deliveries

• طول صف/lag در Redis Streams یا Kafka

• نرخ disconnect / reconnect برای کاربران

• CPU/RAM بر گِیت‌وی‌ها و latency پاسخ

ابزارها و سرویس‌های مرتبط (گزینه‌های سریع)

• Managed Realtime: Pusher, Ably, PubNub — سریع ولی هزینه بر.

• Managed Kafka: Confluent Cloud یا AWS MSK.

• Redis Enterprise (Streams + Streams Consumer Groups) برای durability بهتر.

• NATS JetStream برای پیام‌رسانی سبک و سریع با ویژگی‌های persistence.

جمع‌بندی عملی

• اگر می‌خوای سریع راه بیندازی برای قابلیت‌های UI-like (چت ساده، نوتیف فید)، از Redis Pub/Sub + Websocket Gateway شروع کن.

• اگر پیام‌ها مهم و قابلکلیدی هستند (تراکنشی)، از Kafka/Redis Streams + consumer groups + durability استفاده کن.

• همیشه برای production: TLS، authentication، rate-limit، persistence و observability را پیاده کن.

• تست بار (k6, locust) را از روز اول اجرا کن و SLO تعریف کن.

تیم تحریریه ساب‌گیم ـــــ

Game marketplaces that let users buy/sell accounts, skins, currencies, or services are fundamentally marketplaces of trust. Players trade digital assets with real monetary value; a single high-profile fraud can damage reputation and liquidity overnight. In this article, I’ll share practical building blocks and architectural patterns we used at SubGame to reduce fraud, speed dispute resolution, and keep user friction low — actionable advice you can apply to your own marketplace.

Why trust is different in game marketplaces

Two differences change the game (pun intended):

1. Assets are account-bound & recoverable. A sold account can often be reclaimed by the original owner if email/phone recovery is intact.

2. High velocity, low-ticket & collectible items. Many trades are small but frequent; some items are rare and high-value (sketchy sellers target both).

So solutions must combine automated prevention, smart UX, and a fast human-in-the-loop process for edge cases.

Core components of a trust architecture

1. Identity & verification

   • Email + phone verification (SMS OTP).

   • Optional KYC for high-value sellers (name, ID, selfie).

   • Link external proofs: gaming platform profiles (Steam, Activision, Riot) or social accounts (Discord, Twitter) to raise confidence.

2. Escrow workflow

   • Buyer pays into escrow; funds are released only after verified delivery or after a timeout + seller confirmation.

   • Use a state machine for the order lifecycle: PENDING -> IN_ESCROW -> DELIVERED -> RELEASED | DISPUTED -> RESOLVED.

   • Log immutable events for audits.

3. Reputation & trust score

   • Combine signals: completed sales, dispute rate, account age, verification level, and response time.

   • Present a clear seller score badge (e.g., Verified, Trusted, New) — transparency reduces buyer anxiety.

4. Automated fraud detection

   • Rule-based checks + ML signals (optional): rapid price drops, new account listing many high-value items, repeated chargebacks, inconsistent IP/geolocation vs declared country.

   • Real-time scoring to block suspicious listings or require manual review.

5. Dispute resolution & human review

   • Lightweight UI for filing disputes with structured inputs (screenshots, timestamps).

   • Human reviewers for high-value or ambiguous cases; automation for low-value or obvious scams.

Practical patterns & snippets

Trust score (example)

A simple weighted score you can iterate on:

trust_score = 0.4 normalized(completed_sales) + 0.25 (1 - normalized(dispute_rate)) + 0.2 verification_level + 0.1 account_age_score + 0.05 * response_time_score

Normalize values to 0–1. Tune weights based on observed fraud/fallout.

Escrow state machine (pseudo)

Order { id, buyer_id, seller_id, amount, state }

states = { PENDING, IN_ESCROW, DELIVERED, RELEASED, DISPUTED, REFUNDED }

Transition rules must be guarded (e.g., only buyer confirmation triggers DELIVERED; dispute moves to DISPUTED and triggers review queue).

Event webhook handler (simplified)

FastAPI pseudo-handler

@app.post("/webhook/payment") async def payment_webhook(payload: PaymentPayload): order = get_order(payload.order_id) if payload.status == "paid": order.transition_to("IN_ESCROW") notify_user(order.seller_id, "Buyer paid — please deliver.")

Signals worth tracking for automated detection

• New seller listing > X high-value items in Y hours

• Price anomalies vs the marketplace median for the same item

• Frequent account recovery attempts on the item’s original platform

• IP/geolocation mismatches across seller actions

• Multiple payment failures or chargebacks

Use Redis or a streaming pipeline (Kafka) to build fast alerts and scoring.

UX considerations — reduce friction while increasing safety

• Progressive friction: only show verification/KYC when the risk score passes a threshold or the seller reaches a revenue tier.

• Clear timelines: explain escrow holds (“Funds released after 48 hours unless dispute filed”).

• Deliverability checklist: when sellers deliver an account, give a checklist to confirm handover (email changed, 2FA removed, recovery info updated).

• Default buyer protection: Have a visible “buyer protection” badge and link to the policy to increase conversions.

Operational playbook for disputes

1. Triage automatically: low-value -> auto-refund if evidence is obvious.

2. Medium/high-value -> human reviewer within SLA (e.g., 24 hours).

3. Collector for evidence: logs, screenshots, transaction chain.

4. If the seller is fraudulent, ban + reclaim fees from seller's escrow or bond.

Maintain a separate “trust fund” or insurance pool for refunds until your fraud rate decreases.

Instrumentation & KPIs

Track these closely:

• GMV (Gross Merchandise Value) & GMV growth

• Dispute rate (%) per 1,000 transactions

• False positives (blocked legitimate listings)

• Time-to-resolution for disputes

• Seller lifetime value (LTV) by verification tier

Use dashboards (Grafana) and alerts for KPIs crossing thresholds.

Scaling considerations

• Stateful services (escrow, disputes) must be ACID-safe: Postgres + strong transactional boundaries.

• Real-time systems (such as chat/notifications) scale with Redis pub/sub or managed WebSocket layers.

• Batch & stream processing for fraud signals: stream events to Kafka and run real-time scoring via Flink/Spark or a lightweight Python worker.

Legal & privacy notes

• Know local laws: trading digital goods might require taxation, VAT handling, or be regulated.

• For KYC, handle PII securely: store encrypted, have retention policies, and publish privacy terms.

Conclusion

Trust is the currency of any marketplace — for game marketplaces, investing early in identity verification, escrow, reputation systems, and automated fraud detection pays off by improving liquidity and user retention. Start with simple, explainable rules, instrument everything, and iterate: your scoring models and rules will get better with data.

If you'd like, I can provide a concrete implementation plan (including DB schemas, API specs, and a review checklist) that you can integrate with your Next.js + FastAPI stack.

— SubGame Dev Team

The gaming industry has grown exponentially in recent years, not only as a source of entertainment but also as a thriving economy. Players spend hours leveling up accounts, unlocking rare items, and collecting in-game currencies. This creates a huge market for buying and selling game accounts and items.

To address this need, I started SubGame, a platform designed to provide gamers with a secure, fast, and transparent marketplace. In this article, I’ll walk through the tech stack, architecture, and key lessons learned while building SubGame.

Tech Stack Overview:

• Frontend: Next.js + React + TailwindCSS for responsive, SEO-friendly, and high-performance UI

• Backend: FastAPI for fast, async APIs with Python

• Database: PostgreSQL for relational data

• Caching & Queues: Redis for high-speed caching and message queues

• Authentication & Security: JWT-based auth and secure token storage

• Realtime Features: WebSockets for chat and notifications

• Infrastructure: Docker, Docker Compose, VPS, CDN (ArvanCloud)

• Version Control & CI/CD: GitHub + GitHub Actions

Key Features of SubGame:

1. Secure Transactions: Users’ payments are held in escrow until the item is delivered.

2. Wide Game Support: From PUBG, Call of Duty, Clash of Clans, CS2, Dota 2, World of Warcraft to many more.

3. Realtime Notifications & Chat: Players can communicate instantly and track orders.

4. User-Friendly Dashboard: Sellers can manage listings, and buyers can filter and sort for the best deals.

Challenges and Lessons Learned:

• JWT Management: Ensuring token security and session management was crucial for protecting users.

• Realtime Scaling: Handling chat and notification systems for thousands of concurrent users required careful planning with WebSockets.

• SEO and Performance: Using Next.js for SSR and SSG helped improve search visibility and site speed.

Conclusion:

Building SubGame has been an exciting journey combining gaming passion with web development expertise. The platform empowers gamers with a safe and reliable way to trade accounts and items, while also serving as a case study for modern full-stack development using Next.js and FastAPI.

Check out the platform here: SubGame - Game Marketplace