Designing a university community platform

UniPal is a community platform for university students. Three features: course and professor reviews, a book exchange where students can donate or request textbooks, and a shared repository for study materials. Each feature is distinct. All three share the same users and the same codebase.

The early question was how to model this in MongoDB. A relational database makes the structure obvious: normalized tables, foreign keys, joins. MongoDB does not enforce any of that, which is either an advantage or a trap depending on the decisions you make in the first week.

The book exchange was the most interesting design problem. A book does not exist as a single entity. It exists as something a student is offering, or something a different student is requesting, and the platform needs to match one to the other. Getting the data model wrong here means the matching logic becomes a workaround for a structural mistake.

The book exchange was the clearest design problem. The naive model embeds book details directly in a listing document: a donor listing and a requester listing each contain a copy of the book description. Matching then requires comparing text fields across two collections, which is unreliable and hard to query.

A better model separates the book itself from the listing. A Book document describes the title, author, and subject. A Listing document references the Book by ID, records whether it is an offer or a request, and points to the user. Matching becomes a join on Book ID between offers and requests -- one query, no text comparison.

For the course hierarchy, embedding was wrong. A course document that embeds all its reviews grows unboundedly. Reviews instead reference the course by ID and are stored in their own collection. The hierarchy (department to course to section) uses references rather than embedding at every level because any of those entities can be queried independently.

The data model settled on three main domains: Users, Academic (universities, departments, courses, reviews), and Exchange (books, listings). Each domain uses references rather than embedding for anything that needs to be queried or updated independently.

Book exchange matching works as follows: a student creates a Request listing referencing a Book document. The API queries Listings where type is Offer and book ID matches. Results include the donor's contact information. No text matching. No duplication.

Study materials are the simplest domain: a Material document stores the file metadata and a reference to the course it belongs to. File storage uses the server filesystem for the project scope. A production version would swap that for object storage.

On the frontend, the three features are separate pages but share a navigation and user context. React components are organized by feature, with shared UI primitives extracted once they appeared in more than two places.