Gemma4-Code-Paths.md
· 4.3 KiB · Markdown
Eredeti
Since the DSL is a high-level abstraction, it passes through a **Compiler/Orchestrator** that translates the logic into execution plans.
The routing layer decides which engine to use through a combination of **Static Analysis (at compile time)** and **Resource Mapping (at runtime)**.
---
### 1. Static Analysis: The "Consistency Class"
When you write a module in the DSL, the compiler analyzes the **nodes and operators** used to assign a **Consistency Class** to that workflow.
* **The "Fast Path" Class (Eventual Consistency):**
If a module uses operators like `Suma`, `Delta`, `Tick`, or `Saga.Eventual`, the compiler tags it as `Consistency: Low`. It is routed to the **Combat Engine** (which prioritizes throughput and low-latency updates).
* **The "Safe Path" Class (Strong Consistency):**
If the compiler detects keywords like `Lock()`, `AtomicTransfer`, `Vault`, or `Saga.Atomic`, it automatically upgrades the module to `Consistency: High`. This is routed to the **Trade Engine** (which prioritizes ACID compliance and linearizability).
**Example of the Compiler's logic:**
> *"I see a `Lock` on a `PlayerWallet` and an `AtomicTransfer` call. This cannot be handled by the Fast Path. Routing this entire module to the High-Consistency Cluster."*
---
### 2. Resource-Based Routing (The "Object" Registry)
The routing layer doesn't just look at the *code*; it looks at the **Resource** being accessed. The system maintains a **Global Resource Registry** that defines the required consistency level for every object in the game.
| Resource | Type | Consistency Requirement | Route |
| :--- | :--- | :--- | :--- |
| `WorldBoss.HP` | Global State | Eventual (Delta) | **Combat Engine** |
| `Player.Position` | Spatial State | Eventual (Interpolated) | **Combat Engine** |
| `Player.Inventory` | Asset State | Strong (Atomic) | **Trade Engine** |
| `AuctionHouse.Vault` | Asset State | Strong (Atomic) | **Trade Engine** |
**How the request flows:**
1. Request arrives: `TradeItem(PlayerA, PlayerB, ItemX)`.
2. The Router checks the registry: `ItemX` > `Asset State` > `Strong Consistency`.
3. The Router redirects the request to the **Trade Engine** cluster.
---
### 3. The "Dispatcher" Architecture
Physically, the routing layer acts as a **Smart Dispatcher** (similar to an API Gateway or a Service Mesh like Istio). It manages two entirely different infrastructure stacks:
#### The "Fast Path" Stack (The Combat Engine)
* **Hardware:** High-CPU, high-RAM, optimized for computation.
* **Storage:** In-memory data grids (e.g., Redis, Hazelcast).
* **Behavior:** "Fire and Forget." It processes deltas and syncs them periodically.
* **Goal:** Zero-lag interaction.
#### The "Safe Path" Stack (The Trade Engine)
* **Hardware:** High-I/O, NVMe storage, optimized for disk writes.
* **Storage:** Distributed SQL databases with Paxos/Raft consensus (e.g., CockroachDB, FoundationDB).
* **Behavior:** "Confirm then Commit." It uses a two-phase commit to ensure the data is written to multiple nodes before confirming the trade.
* **Goal:** Zero-loss integrity.
---
### 4. The "Escalation" Trigger (Dynamic Routing)
The most powerful part of this DSL is the ability to **escalate** a request from the Fast Path to the Safe Path in real-time.
**Scenario: The "Critical Hit" Reward**
Imagine a player hits the World Boss. Usually, this is a "Fast Path" event. But the AI determines that this specific hit was a "Legendary One-Shot" that entitles the player to a unique, one-of-a-kind item.
1. **Combat Engine** handles the hit (Fast Path).
2. **AI Director** triggers a "Rare Reward" event.
3. The **Router** detects the `Reward` trigger and **escalates** the workflow.
4. The flow is shifted from the **Combat Engine** > **Trade Engine** to ensure the rare item is minted and delivered with absolute consistency.
### Summary of Routing Logic
| Factor | Fast Path (Combat) | Safe Path (Trade) |
| :--- | :--- | :--- |
| **Trigger** | `Delta`, `Tick`, `Position` | `Lock`, `Vault`, `Atomic` |
| **Resource** | Boss HP, Player XYZ | Inventory, Wallet, Auction |
| **Consistency** | Eventual / Causal | Strong / Linearizable |
| **Infrastructure** | In-Memory > Distributed Cache | Distributed DB > Consensus Log |
| **Latency** | < 10ms | 50ms - 200ms |
| **Risk Profile** | "A bit of lag is okay" | "A single error is a disaster" |
Since the DSL is a high-level abstraction, it passes through a Compiler/Orchestrator that translates the logic into execution plans.
The routing layer decides which engine to use through a combination of Static Analysis (at compile time) and Resource Mapping (at runtime).
1. Static Analysis: The "Consistency Class"
When you write a module in the DSL, the compiler analyzes the nodes and operators used to assign a Consistency Class to that workflow.
- The "Fast Path" Class (Eventual Consistency):
If a module uses operators like
Suma,Delta,Tick, orSaga.Eventual, the compiler tags it asConsistency: Low. It is routed to the Combat Engine (which prioritizes throughput and low-latency updates). - The "Safe Path" Class (Strong Consistency):
If the compiler detects keywords like
Lock(),AtomicTransfer,Vault, orSaga.Atomic, it automatically upgrades the module toConsistency: High. This is routed to the Trade Engine (which prioritizes ACID compliance and linearizability).
Example of the Compiler's logic:
"I see a
Lockon aPlayerWalletand anAtomicTransfercall. This cannot be handled by the Fast Path. Routing this entire module to the High-Consistency Cluster."
2. Resource-Based Routing (The "Object" Registry)
The routing layer doesn't just look at the code; it looks at the Resource being accessed. The system maintains a Global Resource Registry that defines the required consistency level for every object in the game.
| Resource | Type | Consistency Requirement | Route |
|---|---|---|---|
WorldBoss.HP |
Global State | Eventual (Delta) | Combat Engine |
Player.Position |
Spatial State | Eventual (Interpolated) | Combat Engine |
Player.Inventory |
Asset State | Strong (Atomic) | Trade Engine |
AuctionHouse.Vault |
Asset State | Strong (Atomic) | Trade Engine |
How the request flows:
- Request arrives:
TradeItem(PlayerA, PlayerB, ItemX). - The Router checks the registry:
ItemX>Asset State>Strong Consistency. - The Router redirects the request to the Trade Engine cluster.
3. The "Dispatcher" Architecture
Physically, the routing layer acts as a Smart Dispatcher (similar to an API Gateway or a Service Mesh like Istio). It manages two entirely different infrastructure stacks:
The "Fast Path" Stack (The Combat Engine)
- Hardware: High-CPU, high-RAM, optimized for computation.
- Storage: In-memory data grids (e.g., Redis, Hazelcast).
- Behavior: "Fire and Forget." It processes deltas and syncs them periodically.
- Goal: Zero-lag interaction.
The "Safe Path" Stack (The Trade Engine)
- Hardware: High-I/O, NVMe storage, optimized for disk writes.
- Storage: Distributed SQL databases with Paxos/Raft consensus (e.g., CockroachDB, FoundationDB).
- Behavior: "Confirm then Commit." It uses a two-phase commit to ensure the data is written to multiple nodes before confirming the trade.
- Goal: Zero-loss integrity.
4. The "Escalation" Trigger (Dynamic Routing)
The most powerful part of this DSL is the ability to escalate a request from the Fast Path to the Safe Path in real-time.
Scenario: The "Critical Hit" Reward Imagine a player hits the World Boss. Usually, this is a "Fast Path" event. But the AI determines that this specific hit was a "Legendary One-Shot" that entitles the player to a unique, one-of-a-kind item.
- Combat Engine handles the hit (Fast Path).
- AI Director triggers a "Rare Reward" event.
- The Router detects the
Rewardtrigger and escalates the workflow. - The flow is shifted from the Combat Engine > Trade Engine to ensure the rare item is minted and delivered with absolute consistency.
Summary of Routing Logic
| Factor | Fast Path (Combat) | Safe Path (Trade) |
|---|---|---|
| Trigger | Delta, Tick, Position |
Lock, Vault, Atomic |
| Resource | Boss HP, Player XYZ | Inventory, Wallet, Auction |
| Consistency | Eventual / Causal | Strong / Linearizable |
| Infrastructure | In-Memory > Distributed Cache | Distributed DB > Consensus Log |
| Latency | < 10ms | 50ms - 200ms |
| Risk Profile | "A bit of lag is okay" | "A single error is a disaster" |