Business problem
A gaming digital-goods marketplace needs distinct customer and administrative experiences with a shared backend.
Sellers require onboarding and game-specific offer forms before production commerce rails are complete.
Security, auditability and multi-environment delivery must be established early.
Project context
The architecture separates a Next.js marketplace, a Next.js admin portal and a Node.js/Express/TypeScript API.
Foundations cover authentication, catalog/admin primitives, seller applications, dynamic offer forms, notifications, chat/support, localization architecture and deployments.
Team context
Sole product engineer responsible for product architecture, backend API, marketplace frontend, admin portal, database design, authentication and security, UI implementation, cloud infrastructure, environment configuration, CI/CD and deployments.
Responsibilities
- Product architecture
- Backend API
- Marketplace frontend
- Admin portal
- Database design
- Authentication and security
- UI implementation
- Cloud infrastructure
- Environment configuration
- CI/CD and deployments
Architecture
Marketplace and admin clients communicate with a shared TypeScript API.
MySQL on AWS RDS stores domain data; Google Cloud Run, Cloud Storage and Secret Manager support API runtime and secrets.
Socket.IO supports realtime communication for chat and support flows.
GameSpax system components
Conceptual ownership map for hiring audiences. Internal topology, credentials and sensitive operational data are intentionally omitted.
- Next.js marketplace
- Next.js admin portal
- Node.js / Express / TypeScript API
- MySQL and Sequelize
- AWS RDS
- Google Cloud Run
- Google Cloud Storage
- Secret Manager
- Vercel
- Socket.IO
System overview
Marketplace and admin clients connect to the API, which uses RDS, storage and realtime services.
- Marketplace
- Admin portal
- Express / TypeScript
- Socket.IO
- MySQL / RDS
- Cloud Storage
- Secret Manager
- Cloud Run
- Vercel
Separate web and admin authentication planes
WEB and ADMIN session planes remain isolated while sharing API authorization concepts.
- Marketplace cookies
- Customer auth flows
- Opaque HttpOnly session
- Admin cookies
- Staff auth flows
- Roles / permissions / audit
Seller offer-form flow
Admin-defined schemas drive reusable seller offer forms for different games.
- Admin defines offer schema
- Game-specific seller fields
- Reusable form rendering
- Seller submission to API
Systems
Frontend
- Marketplace application for customer-facing MVP flows
- Separate admin portal for operational configuration
- Localization architecture shared across clients
- Admin-template cleanup and remapping for gaming modules
Backend
- TypeScript API as the shared application core
- Opaque HttpOnly session model with separate web and admin session planes
- Roles, permissions and audit logging
- Seller applications and dynamic offer-form schemas
- Notifications, chat and support endpoints
Database
- MySQL with Sequelize
- AWS RDS hosting
- Schema support for categories, games, seller applications, offers, auth and audit concerns
Cloud infrastructure
- Google Cloud Run for API deployment
- Google Cloud Storage
- Secret Manager
- Vercel for frontend applications
- AWS RDS with controlled external access for the MVP
- Separated environment configuration across repositories
Security
- Opaque HttpOnly sessions
- Separate WEB and ADMIN session planes
- Argon2id password hashing
- MFA with TOTP and recovery codes
- Passkey / WebAuthn foundations for backend and admin
- Audit logging
- Role-based access control
Integrations
- Google OAuth
- Email verification and password recovery flows
- Realtime Socket.IO chat/support
Technical deep dives
Implemented MVP foundations
Completed or implemented foundations include registration and login, email verification, password recovery, Google OAuth, MFA, passkey backend/admin foundation, separate web and admin cookie sessions, roles and permissions, audit logs, categories, games, seller applications, dynamic offer-form system, notifications, chat and support, localization architecture, admin foundation and deployment environments.
These foundations establish the product spine. They are not a claim that marketplace commerce is production-complete.
Cross-repository coordination
Backend, marketplace and admin live in separate repositories, so API contracts, auth assumptions and shared domain language must stay aligned.
Changes to offer schemas, session behaviour or localization contracts require coordinated updates across clients and the API.
Authentication and security
Sessions use opaque HttpOnly cookies with separate WEB and ADMIN session planes so marketplace and admin auth do not collapse into one cookie context.
Password hashing uses Argon2id. MFA supports TOTP and recovery codes. Passkey/WebAuthn foundations exist for backend and admin paths.
Audit logging and role-based access reinforce operational accountability. Secret names, cookie-domain internals and attack-sensitive configuration details are intentionally omitted.
Legacy admin-template cleanup
The starting admin template included property-marketplace sections that were not relevant to gaming digital goods.
Gaming modules were remapped, incomplete sections were marked appropriately, and legacy navigation was prevented from reappearing in the operational IA.
Dynamic offer forms
Different games require different seller fields, so a single rigid listing model is a poor fit.
Admins can define offer schemas that drive reusable form rendering for seller submissions.
Localization architecture
The MVP includes multi-language and currency architecture with shared contract consistency across clients.
This does not claim that every translation string has been manually reviewed end-to-end.
Infrastructure connectivity trade-off
Private GCP-to-AWS connectivity was evaluated. A lower-cost connectivity approach was selected for the delivery stage.
AWS RDS therefore uses controlled external access with SSL, restricted security rules, strong credentials and Secret Manager — not an unrestricted public database posture.
The architecture retains a future migration path to private networking when the product is ready for that investment.
Technical challenges
Keeping three repositories coherent
API contracts must stay synchronized across backend, marketplace and admin.
- Shared auth assumptions
- Offer-form schema alignment
- Localization contract consistency
Security before commerce completeness
Auth, sessions, MFA and audit logging were prioritized ahead of unfinished commerce rails.
- Separate web/admin session planes
- Argon2id, MFA and passkey foundations
- No claim of completed payments or wallet systems
MVP infrastructure cost vs private networking
Private networking was deferred in favour of a controlled external-access MVP approach.
- SSL and restricted security rules
- Strong credentials via Secret Manager
- Documented path to private networking later
Trade-offs
Security foundations before checkout
Decision: Ship authentication, roles, audit logs and offer-form infrastructure before payments and wallet flows.
Consequence: Hiring audiences see an honest MVP boundary instead of overstated commerce readiness.
Controlled external RDS access for MVP cost
Decision: Accept controlled external database access with compensating controls rather than immediate private GCP-to-AWS networking.
Consequence: Lower near-term cost with explicit hardening requirements and a future private-networking migration path.
Not presented as complete
The following areas are not claimed as finished product capabilities in this case study.
- Full marketplace listing lifecycle
- Cart
- Checkout
- Payments
- Wallet ledger
- Withdrawals
- Disputes
- Complete commerce production readiness
Results
Coherent MVP architecture
Established separated marketplace/admin clients, a TypeScript API and cloud deployment foundations.
Security-first product spine
Implemented session separation, hashing, MFA and audit logging before unfinished commerce features.
Honest delivery status
Documented incomplete commerce areas explicitly so the MVP is not mistaken for production marketplace readiness.
Constraints
- Checkout, payments, wallet, withdrawals and disputes are not presented as completed features
- No public project employment dates displayed
Stack
- Next.js
- Node.js
- Express
- TypeScript
- MySQL
- Sequelize
- AWS RDS
- Google Cloud Run
- Google Cloud Storage
- Secret Manager
- Vercel
- Socket.IO