Node.js,Fastify,Prisma,PostgreSQL,Backend Architecture
Building a Transaction-Safe Multiplayer Game Backend
Designed and implemented a transaction-safe multiplayer backend that mirrored the Angular game engine, enabling persistent game state, authenticated gameplay, API-driven actions, and multiplayer synchronization.
The Problem
After validating gameplay mechanics through Angular and AI-driven testing, the next challenge was supporting real multiplayer gameplay through a persistent backend.
Unlike frontend development, backend development provided no visual representation of cards, hands, decks, melds, or player tableaus. Most debugging relied on API responses, logs, database state, and serialized game objects.
This created a unique challenge where gameplay logic had to remain correct even though the state being manipulated was largely invisible during development.
Every action needed to preserve game integrity while supporting persistence, authentication, multiplayer synchronization, and future scalability.
TL;DR
- Problem: The frontend game engine needed to evolve into a persistent multiplayer platform while preserving gameplay integrity.
- Solution: Built a Fastify + Prisma backend that mirrored the Angular game engine and validated every action through a centralized server-side rules engine.
- Impact: Enabled authenticated multiplayer gameplay with persistent state, deck validation, and transaction-safe action processing.
Technical Leadership
- Designed the backend architecture from scratch around the existing Angular game engine.
- Created a mirrored server-side game engine to ensure rule consistency between frontend and backend.
- Identified deck integrity validation as a critical requirement for multiplayer reliability.
- Implemented transaction-safe action processing to prevent race conditions during gameplay.
- Established API contracts capable of supporting future multiplayer enhancements.
What I Did
The backend became the authoritative source of truth for every multiplayer game.
Rather than trusting client-side actions, every move was validated through a mirrored server-side game engine that enforced the same gameplay rules established during Angular development.
Persistence evolved through multiple stages. Early development used Firebase Firestore as a temporary persistence layer, allowing game state, player actions, and API contracts to mature while gameplay rules were still being refined.
Once the structure of the game state became stable and consistency requirements were well understood, persistence was migrated to PostgreSQL using Prisma to support stronger relational modeling, scalability, and long-term maintainability.

- Built REST APIs using Fastify for game creation, player joining, game actions, and state retrieval.
- Created a mirrored server-side game engine that reflected the Angular reducer architecture.
- Started persistence using Firebase Firestore, allowing game state to be stored and validated while the API contracts, game actions, and state structures continued to evolve.
- Used Firestore as an intermediate persistence layer to rapidly iterate on game engine development before committing to a relational data model.
- Migrated persistence to PostgreSQL using Prisma once gameplay state became stable and data consistency requirements were better understood.
- Implemented Firebase authentication to secure multiplayer actions.
- Created APIs for game actions, discard pile state, player tableau state, hand state, and overall game state synchronization.
- Implemented deck integrity validation to ensure exactly one copy of each card existed in 2-player games and exactly two copies existed in 3-4 player games.
- Added transaction-safe processing to prevent conflicting multiplayer actions from corrupting game state.
- Created detailed logging and state inspection tooling to compensate for the lack of visual debugging capabilities.
Testing and Validation
Validation focused heavily on ensuring server-side state matched gameplay expectations despite the lack of visual feedback.
Game state was continuously compared against expected deck counts, player hands, discard piles, melds, and score calculations.
- Verified deck composition rules across 2-player, 3-player, and 4-player matches.
- Validated that every card existed exactly once or twice depending on game configuration.
- Confirmed game actions produced expected state transitions.
- Verified discard pile, hand state, and tableau state synchronization.
- Tested authenticated API access using Firebase Admin validation.
- Validated transaction-safe processing under repeated gameplay scenarios.
- Used AI-driven gameplay to continuously exercise backend action processing.
Outcome
- Successfully deployed a production multiplayer backend.
- Eliminated duplicate card scenarios through deck integrity validation.
- Established a single source of truth for multiplayer gameplay.
- Enabled persistent game sessions and player reconnection.
- Created a scalable API foundation for future multiplayer enhancements.
- Reduced gameplay defects by validating every action through a centralized server-side engine.