Why One Database Isn’t Enough: Building a Hybrid Architecture for CampusSwap

When I started building CampusSwap, a peer-to-peer marketplace for students, I hit a classic architectural crossroads: Relational or Non-relational?

Marketplaces are messy. Product listings change constantly—a textbook has different metadata than a mini-fridge. But when money and trust are involved, transactions need to be rock-solid. Here is why I chose a hybrid database approach to get the best of both worlds.

1. The Flexibility of MongoDB (The Listings)

Student listings are diverse. One student might list a "Dorm Chair" with dimensions and material, while another lists "Calculus Notes" with a PDF preview. Using MongoDB, I could store these as flexible documents without a rigid schema. This allowed for:

• Fast iterations on product categories.

• Easy storage of diverse metadata.

• High-speed retrieval for browsing and searching.

2. The Integrity of PostgreSQL (The Transactions)

When a trade happens or a user verifies their student identity, there is zero room for error. I chose PostgreSQL to handle:

• User Authentication: Ensuring every user is tied to a verified .edu email.

• Transactional Data: Using ACID compliance to ensure that a "Sold" status is reflected accurately across the board.

• Relationships: Managing the complex web of who bought what from whom.

3. Real-Time Communication with Socket.io

A marketplace dies without communication. I integrated Socket.io to build a real-in-app messaging system. By keeping the chat states separate from the core transactional data, I ensured that a spike in "Is this still available?" messages wouldn't slow down the checkout process.

The Verdict

By engineered a hybrid architecture, I didn't have to compromise. CampusSwap became a platform that is as flexible as a Craigslist-style board but as secure as a modern fintech app.

Key Lesson: Don't try to force one tool to do everything. Use the right tool for the specific data type.