GameFlix
GameFlix is a game rental and discovery concept built around a secure account flow, a modular service architecture, and a clear path from browsing to renting to reviewing. The project started with security and data planning, then expanded into service design and effort estimation.
Overview
GameFlix was designed as a platform for people who want to browse games, manage rentals, and leave feedback without jumping between disconnected tools. The app concept centers the account flow first so the rest of the experience has a stable foundation.
The implementation work focused on the entry point, while the larger project package mapped out catalog browsing, review handling, payment logic, and recommendation support as a scalable system.
Project Materials
Each deliverable captures a specific layer of the project, from the first security questions to the final planning estimate.
- Source Archive - A clean copy of the codebase used to demonstrate the Spring Boot login and registration foundation.
- Login and Registration Security - Explains password hashing, duplicate-user checks, and why secure storage matters.
- Data Model in 3NF - Describes the user, game, review, and payment relationships in a normalized schema.
- Microservices and Endpoints - Outlines the user, catalog, and review services plus the API routes that support them.
- Architectural Diagram - Summarizes the frontend, services, databases, and APIs that make up the larger GameFlix flow.
- Function Point Analysis - Estimates the system scope at 110 function points and explains how that number can guide planning.
- Sprint Plan - Lays out the first sprint goals, user stories, and estimated effort for the highest-priority features.
Problem and Scope
Game rental experiences often split the user journey across too many steps: account creation, search, game detail review, payment, rentals, and feedback. If the structure is not clear, the experience feels like several separate tools stitched together.
The project scope focused on the parts that have to work first: secure sign-up and login, a clean catalog model, review support, and the ability to extend into payments and recommendations without rebuilding the entire system later.
- New users need a simple path to create accounts and log in.
- Browse and search need to stay fast once the catalog grows.
- Reviews and rentals need separate but connected records.
- The backend should support future services without becoming brittle.
Account Security
The login and registration work set the security tone for the whole project. Rather than storing plain text passwords, the design centers on hashed credentials, duplicate-user checks, and a registration flow that does not let obvious conflicts slip through.
The codebase reflects that narrow but important foundation. A Spring Boot controller handles the form routes, the service layer checks for duplicate usernames, and the user model keeps the data organized for later expansion.
Password Handling
The security brief emphasizes why password hashing matters, what goes wrong with plain text storage, and how BCrypt-style encoding slows down brute-force attacks.
That framing is useful because it keeps the implementation grounded in practical risk instead of treating authentication like a checkbox feature.
Data Model
The ERD in 3NF describes the core relationships needed to keep GameFlix organized. A user can create multiple reviews and make multiple payments, while each review or payment belongs to one user. Games follow the same one-to-many pattern when they connect to reviews or purchases.
That structure matters because it keeps the system flexible without repeating data in several places. Normalization also makes the later services easier to reason about, since the relationships stay clear from the start.
Normalized Structure
The data model gives the project a stable spine: users, games, reviews, and payments all connect in a way that supports growth without duplicating the same record in multiple tables.
That is the part of the project that makes the later architecture believable. The services can stay modular because the underlying data is already organized.
Microservices and Endpoints
The microservices document defines the core platform around three services: user, catalog, and review. The user service handles registration, login, and profile data; the catalog service supports browsing and filtering; and the review service stores ratings and comments.
The endpoints make the scope concrete. Register and login routes support the account flow, catalog routes expose game data, and review routes connect user feedback to each game record.
Endpoints That Matter
Register, login, browse, search, view game details, and post reviews are the routes that define the first usable version of GameFlix.
That mix is enough to let a user move from account creation into browsing and feedback without the architecture feeling overbuilt.
System Architecture
The architectural diagram expands the project beyond the first three services and shows the larger system the app could grow into. It places the frontend at the center and connects user, catalog, review, and payment services to their own databases and APIs.
This is also where the recommendation idea becomes practical. Once the system can see a user's rentals, available games, and community feedback together, it has enough structure to suggest new titles with more context.
Frontend to Services
The big idea in the diagram is separation: each service owns its job, each database stores its own data, and the API layer keeps those pieces coordinated.
That separation is what makes the project feel scalable instead of tied to one screen or one prototype state.
Planning and Estimation
The sprint plan puts login and registration first, which makes sense because account access is the entry point for everything else. It also shows the broader user story map: browse games, rent games, submit reviews, and view history with recommendations.
The function point analysis gives the work a more formal estimate. With a total of 110 function points, the project has enough size to justify a modular backend but not so much complexity that the first release becomes unwieldy.
Delivery Focus
The first sprint centered on the account experience because that was the highest-value part of the system to stabilize early.
Planning poker and the function point estimate both reinforced the same idea: the most important tasks deserved the first engineering attention.
Estimation Check
The chart is useful because it shows how planning changes once real work starts moving. A clean estimate is only useful if it helps the team adjust without losing sight of the goal.
That is the same logic behind the whole project: plan the structure early, then keep the implementation flexible enough to absorb what testing reveals.
Conclusion
GameFlix became more coherent once the work was organized around the user journey instead of around isolated deliverables. The security brief, ERD, service design, architecture, and sprint planning all pointed to the same thing: a game platform needs a stable account foundation before the rest of the experience can scale cleanly.
As a portfolio project, GameFlix shows more than a visual concept. It shows how I think through secure onboarding, normalized data, service boundaries, and effort estimation when I design a system that has to work across browsing, renting, and feedback.