5.1 Architecture Decisions - JoshuaJewell/IDApTIK GitHub Wiki

πŸ— Architecture Decisions – IDApTIK

🟒 Beginner: What is an architecture?

Before we talk code, let’s imagine building a house:

  • The foundation = The core game engine (Rust + TypeScript)
  • The walls = Multiplayer framework (Elixir for fault tolerance)
  • The doors & windows = How players interact (GraphQL for fast data exchange)

Everything needs to be strong and flexible, just like IDApTIK’s asymmetric multiplayer design.

πŸ”΅ Novice: How do we structure IDApTIK?

We use three key layers to make sure the game runs smoothly:

  1. Frontend (TypeScript + WASM) β†’ UI, player controls, real-time visuals
  2. Backend (Rust + Elixir) β†’ Multiplayer coordination, AI-driven security teams
  3. Middleware (GraphQL) β†’ Fast hacker/infiltrator data exchange, structured queries

Our goal is fault-tolerant, scalable multiplayer mechanics that balance performance, adaptability, and strategic complexity.

⚫ Advanced: Optimization & scalability strategies

πŸ”₯ Rust-powered execution models β†’ High-performance physics and event processing
πŸ”₯ Elixir-driven rollback resilience β†’ Ensuring multiplayer interactions remain fault-tolerant
πŸ”₯ Podman-based security AI scaling β†’ Containerized defensive routines adapting to infiltrator strategies
πŸ”₯ GraphQL for asymmetric data requests β†’ Hacker teams get limited, real-time intelligence while security firms use structured responses
πŸ”₯ Redis-powered caching β†’ Reducing lag during real-time player interactions