Project: NexKey
Cloud-Based Game Key Store
A cloud-based game key reseller store supporting multiple platforms, built on Google App Engine with a Flask backend, a React frontend, and a hybrid SQL/NoSQL data layer for secure, scalable transactions.
Project Log
NexKey is a marketplace for reselling game keys across multiple platforms. It's built as a lightweight, scalable system rather than one big monolith, using managed cloud services where they made sense instead of running everything by hand.
The React frontend is built with Vite and served as a static bundle straight from the Flask backend, which handles business logic and role-based access for users, sellers, and admins. Data is split across three storage types depending on how it's used: SQL for relational records, NoSQL for fast-changing session data, and a cloud storage bucket for game images.
Tech Stack:
- React (Vite) & Tailwind CSS: Component-based frontend, built as a static bundle
- Python (Flask) + Gunicorn: REST API and business logic
- Google App Engine: Backend hosting and automatic scaling
- Google Cloud Run: Serverless functions for offloaded tasks like activity logging
- Google OAuth 2.0 + JWT: Third-party login and stateless API authentication
- SQL + NoSQL (hybrid): Relational data for users, keys and sales; NoSQL for sessions and search data
- Cloud Object Storage: Game images, decoupled from the app for future CDN delivery
Highlights:
- Split data across three storage types based on how it's used: SQL for relational records, NoSQL for short-lived sessions, and object storage for game images
- Used Cloud Run to offload activity logging (logins, purchases, sign-outs) so it doesn't slow down the main request path
- Combined Google OAuth 2.0 with a custom JWT system: short-lived tokens in NoSQL for speed, longer-lived "remember me" tokens in SQL for security
- Keys are only revealed after a successful purchase callback, so nothing sensitive is exposed before payment completes
Key Contributions:
- Designed and built the whole system solo: architecture, database design, API, frontend, and deployment
- Designed the relational schema (Users, GameKeys, Sales, UserTokens, ActivityLog) with foreign key constraints to keep transaction records consistent
- Weighed Flask against Django, and App Engine against AWS and Kubernetes, and documented the trade-offs for each
- Deployed a fully working version of the store to Google App Engine as a live demo (since taken down, as this was a project rather than a live product)
Database Design
NexKey uses a hybrid data model: SQL for persistent, relational data and NoSQL for short-lived session state, chosen to match the store's actual read and write patterns rather than forcing everything into one database.
Gallery
Select below to expand.
Key Features
Role-Based Access
Users, sellers, and admins each get a different set of permissions, enforced consistently through the REST API.
Hybrid Data Storage
Relational data lives in SQL for integrity and reporting, while fast-changing session and search data lives in NoSQL for quicker reads and writes.
Secure Authentication
Google OAuth 2.0 for sign-in, backed by short-lived JWTs for API requests and longer-lived tokens for "remember me" sessions.
Serverless Activity Logging
Logins, purchases, and sign-outs are logged asynchronously through Cloud Run, keeping the main request path fast.
Decoupled Media Storage
Game images sit in a cloud storage bucket rather than the database, keeping the store lighter and ready for future CDN delivery.
Custom REST API
Every CRUD operation runs through validated, role-checked endpoints, with keys only released after a confirmed purchase.
Design Choices & Trade-offs
Flask was chosen over Django for the backend. It's lighter, has less built-in structure to work around, and suited the scope of this project better than a full-featured framework would have.
Google App Engine was chosen for its managed scaling and fast deployment workflow, which fit the project's timeline well. For a larger, longer-term system, AWS or a Kubernetes-based setup would likely offer more flexibility and vendor neutrality.
The biggest challenges were coordinating IAM permissions between cloud services, getting the frontend build context right for deployment, and wiring up OAuth callbacks correctly. Future versions could simplify the SQL/NoSQL split further with an event-driven or multi-model database approach.