Architecture Log: Cross-Platform Multiplayer Ecosystem

Context

The architecture requires an in-memory store for caching and ephemeral session management. As a Day-0 project, capital efficiency and deployment speed were primary constraints. Benchmarking of external data stores (e.g., Memcached, Dragonfly) was bypassed to avoid introducing networking overhead outside our primary AWS VPC.

Decision

Intercepted the default Redis integration and provisioned AWS ElastiCache (Valkey) as the foundational in-memory store.

Rationale

• Ecosystem Anchoring: Restricting the selection to native AWS managed services eliminates the operational overhead of VPC peering and third-party billing.
• Capital Efficiency: AWS ElastiCache for Valkey operates at a 33% lower cost compared to equivalent Redis nodes, optimizing initial startup runway.
• Risk Mitigation: Valkey acts as a 1:1 API drop-in replacement for Redis. If Valkey suffers from maintenance degradation, the connection string can be migrated back to ElastiCache Redis with minimal code changes.

Context

Instead of blindly jumping into a standard desktop setup, I spent time researching multi-platform distribution bloat. The business needed a standalone game launcher that could handle complex social features, cross-platform UI, and high-speed binary delta patching without introducing redundant, platform-specific codebases or massive framework footprints.

Decision

Build a Flutter Frontend connected to a Rust Core via flutter_rust_bridge (FFI).

Rationale

• Platform Isolation: Both Flutter and Rust allow conditional compilation. We carry only the bare-metal disk I/O and heavy Rust binaries (BLAKE3, mmap) strictly where they are needed on desktop, keeping the Android build completely lightweight.
• Resource Optimization: Consolidating UI development into Flutter minimizes duplicate engineering effort for the same features across desktop and mobile teams.
• Native Extensibility: Flutter's method channels provide an essential escape hatch if platform-level implementations diverge.
• Discarded Alternatives: Electron was rejected due to its bundled Chromium footprint and lack of mobile support. Tauri was passed over because its Android ecosystem was too immature for our mobile roadmap.

Context

The core gameplay loop demands high-frequency data synchronization. The Unity client, especially on constrained hardware, is susceptible to frame drops from Garbage Collection (GC) spikes during heavy serialization workloads. CPU allocation overhead and AWS egress bandwidth must be minimized.

Decision

Implement gRPC/Protobuf for all high-frequency game data and WebSockets. Utilize hash-gated fetching for large payloads, and restrict JSON/REST to initial authentication.

Rationale

• GC Mitigation: JSON was rejected for game-state transfer. Parsing large JSON strings in C# creates heap allocations, causing GC stutter. Protobuf's binary serialization reduces client-side processing overhead.
• Egress Cost Optimization: Protobuf's binary format reduces payload size compared to verbose JSON, lowering AWS data transfer out (DTO) costs at scale.
• Hash-Gated Fetching: To mitigate bandwidth waste, large profile payloads are prefaced with a lightweight hash comparison. The Unity client only fetches and deserializes the full binary payload if the server-side hash invalidates the local cache.
• Architectural Exception: JSON/REST is retained for identity management. Authentication requests are infrequent, making the GC impact negligible and simplifying the web portal's tooling. This allows us to utilize standard web tooling for our web portal without forcing complex gRPC-web proxies into the browser layer.

Context

I stepped away from pure backend infrastructure into product strategy to pitch a transformation for our web portal. Our goal wasn't just to replace our legacy Wix setup, but to build a highly cinematic web identity inspired by the presentation of GTA-6—requiring absolute control over the DOM to drive an immersive scrollytelling experience.

Decision

Build a custom Svelte application deployed via Cloudflare Pages and driven by Lenis scroll mechanics.

Rationale

• Granular Reactivity: Svelte provides the precise state reactivity needed to execute heavy scroll animations (Lenis and GSAP) flawlessly without framework-induced frame drops or stuttering.
• Cost & Control Optimization: Moving off Wix grants absolute control for advanced SEO strategies while Cloudflare Pages leverages edge networks to reduce our portal OpEx to zero.
• Edge Computing Integration: Svelte server actions compile to Cloudflare Workers with zero cold-starts, allowing secure proxying to our AWS backend and native Web Crypto API integration for biometric passkeys.
• Discarded Alternatives: React was rejected due to Virtual DOM overhead and unnecessary architectural complexity which makes it easy to write poorly optimized code without strict enforcement standards. SolidJS offered superior raw performance but its developer experience was less conducive to rapid iteration.
• Hiring Risk Mitigation: Established a strict 3-month pre-production threshold. If staffing targets for Svelte engineers are missed, the architecture has a pre-approved fallback to unconditionally revert to React to protect the delivery timeline.

Context

During R&D, a strict 8GB shared memory limit was identified on the Meta Quest 3. Loading 1:1 scale environments as monolithic scenes would lead to Out-Of-Memory (OOM) crashes on standalone VR hardware.

Decision

Architect the technical blueprint for an asynchronous Addressable Spatial Grid, shifting away from standard Unity scene loading.

Rationale

• Risk Identification: Manual modeling of a cross-platform open world was determined to be a production risk without aggressive LOD and texture-stripping pipelines.
• Hardware Overrides: The architecture dictates dynamically streaming asset chunks in and out of memory based on the player's active radius, appending platform-specific suffixes (e.g., baked lighting for Android, dynamic lighting for PC).
• Domain Handoff: Drafted as an R&D blueprint to serve as a mandate for incoming Technical Art and Client Engineering leads, providing the framework needed to execute CI/CD automation.

Context

As our engineering footprint expanded, I stepped in to identify the standards needed to safeguard long-term maintainability for our incoming junior Unity developers. We faced severe risks of platform dependency bleeding (e.g., PC scripts referencing VR SDKs), which would break the CI/CD pipeline and slow down development cycles.

Decision

Enforce strict, compiler-level isolation using Unity Assembly Definitions (.asmdef) alongside multi-layered scene-splitting across the project structure.

Rationale

• Interface-First Architecture: Core assemblies contain only hardware-agnostic interfaces (e.g., `IInteractable`). Platform-specific assemblies implement these interfaces but are forbidden from referencing each other, ensuring clean compiler boundaries.
• Parallel Workflows: Splitting monolithic scenes into layers unblocks our junior developers, allowing artists, designers, and systems engineers to lock and work on different files simultaneously without merge conflicts.
• Third-Party Isolation: Enforces the Wrapper Pattern. All third-party plugins when possible are sandboxed within isolated `.asmdef` fences to protect our architectural core from vendor pollution.

Context

The backend needs to handle stateless HTTP traffic (Identity) and highly stateful, long-lived WebSocket connections (Matchmaking, Chat). The planned deployment on AWS App Runner was impacted by the service's scheduled deprecation.

Decision

Abandoned App Runner. Bifurcated the compute layer: stateless APIs deploy via AWS ECS Express Mode, while WebSockets route to ECS Fargate.

Rationale

• Vendor Deprecation: Immediate migration to the core ECS control plane ensured long-term platform stability.
• Capital Efficiency: ECS Express Mode reduces infrastructure expense for stateless requests during development by sharing a single Application Load Balancer (ALB) across multiple services.
• Protocol Alignment: Express Mode handles burst-scaling for HTTP authentication, while Fargate provides the granular network control required to prevent websocket drops during sustained sessions.
• Scale-Out Path: Standardizing on the ECS control plane ensures a smooth migration of stateless APIs to Fargate when traffic hits production scale.