> For the complete documentation index, see [llms.txt](https://docs.playnance.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.playnance.com/data-flow/data-flow.md). # Data Flow ## Data Flow Architecture Playnance games are designed around event-driven, real-time data movement.\ Every user action, game event, and blockchain transaction flows through a layered pipeline that prioritizes speed, determinism, and observability. This section explains how data moves across PlayBlock — from external game providers and on-chain smart contracts, through internal services, and out to real-time user interfaces and analytics systems. ### 1. External Inputs & Game Providers Playnance integrates with external APIs for certain game verticals and partners. These APIs provide: * Game actions (bets, wins, round results) * Player session events * Provider-specific metadata and callbacks All external data enters through validated API gateways, where: * Requests are authenticated * Payloads are normalized * Idempotency and replay protection are enforced This ensures external variability never leaks into core settlement logic. ### 2. Core Application Services Once validated, data is processed by internal services responsible for: * Game logic * Bet execution * Settlement orchestration * Risk and limits enforcement These services are fully decoupled and communicate asynchronously, allowing the system to scale horizontally without tight coupling. ### 3. Messaging & Event Distribution (Kafka) At the heart of PlayBlock’s internal data flow is [Apache Kafka](https://kafka.apache.org/). Kafka is used to: * Distribute game events between services * Decouple producers (games, executors) from consumers (analytics, payouts) * Guarantee ordered, replayable event streams * Absorb traffic spikes without back-pressure Every meaningful system action becomes an event: * Bets placed * Wins settled * Games finalized * Treasury movements This event-first design is critical for reliability and auditability. ### 4. Fast Access & State Caching (Redis) For low-latency operations, Playnance relies heavily on [Redis](https://redis.io/). Redis is used for: * Hot state caching (sessions, balances, game state) * Deduplication and idempotency keys * Rate-limiting and locks * Short-lived coordination data between services Redis allows services to operate at sub-millisecond latency without constant database or blockchain calls. ### 5. Operational Storage & Logs (MySQL) Structured operational data is stored in [MySQL](https://www.mysql.com/). MySQL is the source of truth for: * Players and accounts * Game metadata * Financial logs * Provider requests and responses * Audit and reconciliation records This layer prioritizes consistency and traceability over raw speed. ### 6. On-Chain Event Indexing (ClickHouse) Smart contracts deployed on PlayBlock emit a high volume of on-chain events. These events are: * Collected via JSON-RPC and WebSocket listeners * Normalized by sync services * Written into [ClickHouse](https://clickhouse.com/) ClickHouse is optimized for: * Massive insert throughput * Time-series queries * Historical analysis * Cross-contract analytics This separation keeps analytics workloads from impacting live gameplay. ### 7. Real-Time Streaming to Clients (PieHost) To power live experiences, PlayBlock streams selected events in real time via [PieHost](https://piehost.com/). Used for: * Live odds and price updates * Order books and liquidity changes * Game state transitions * User-facing dashboards This enables WebSocket-based, sub-second updates without polling or API overload. ### 8. Blockchain Transparency (Blockscout) All on-chain activity on PlayBlock is publicly observable via [Blockscout](https://www.blockscout.com/). Blockscout provides: * Transaction visibility * Smart contract inspection * Event logs * Treasury and executor transparency This ensures PlayBlock remains verifiable, auditable, and trust-minimized. ### End-to-End Flow Summary 1. External API or user action enters the system 2. Core services validate and process the request 3. Events are emitted to Kafka 4. Redis supports fast state access 5. MySQL stores operational truth 6. Smart contracts emit on-chain events 7. ClickHouse indexes events for analytics 8. PieHost streams live updates to clients 9. Blockscout exposes everything publicly This data flow design allows PlayBlock to achieve: * High throughput without bottlenecks * Deterministic settlement * Real-time user feedback * Strong auditability * Clean separation between gameplay, analytics, and infrastructure It is purpose-built for gaming, finance, and real-time blockchain systems. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.playnance.com/data-flow/data-flow.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.