Multi-Vendor Product Catalogue with Faceted Search on MongoDB

The problem: every category has different attributes

A phone has RAM, storage, battery capacity and a PTA approval status. A pair of shoes has size, colour and material. A book has an author, a publisher and a language. A multi-vendor marketplace has to store all of them, let hundreds of vendors add products without a developer, and still let a shopper filter "laptops, 16 GB RAM, under a budget, in stock" and see how many results each filter would leave.

In a relational database this usually becomes either a table with hundreds of mostly empty columns or an entity-attribute-value (EAV) table that is painful to query and index. MongoDB's flexible documents look like the answer, until the first slow filter query shows that flexible does not mean free. Getting this right is a data modelling problem, and that is what makes it a strong final year project.

What already exists and the gap

• Daraz and Amazon show different specification tables and filters per category, backed by large search clusters and dedicated teams.
• Shopify handles category differences with product variants and metafields, and WooCommerce stores product attributes as taxonomies and post meta, which gets awkward to filter well as a catalogue grows.
• Algolia, Elasticsearch and OpenSearch are the usual engines behind faceted search, added as a second system that has to be kept in sync with the main database.

The gap for an FYP is not to out-build Daraz. It is a small, honest catalogue that shows how far one well modelled MongoDB database can go on its own, with measurements, before a separate search engine is needed.

Inspiration

MongoDB's Building with Patterns series introduced the attribute pattern for exactly this case: move the varying fields into an array of key and value pairs so one compound index covers every attribute. Pair that with query-driven design, where you list the queries first and shape documents around them, which is how MongoDB's own data modelling guidance teaches it, and with the index internals covered in courses such as CMU's database systems course.

What you build

• Shoppers: search by text, pick a category, filter by price and attributes, see counts next to every filter value, sort and page through results.
• Vendors: add and edit products using a form that changes by category, with validation that rejects a phone without storage or a shoe without a size.
• Admin: manage categories and which attributes each one exposes as filters.

Main flows: vendor adds a product, shopper narrows a search with three filters, the results and counts update, shopper pages deep into the results.

The technically interesting part

This project is about modelling decisions, each of which you should be able to defend with a measurement.

• Attribute pattern versus fixed fields. Store common fields (title, price, vendor, category, stock) as normal fields and the varying ones as attrs: [{ k: "ram_gb", v: 16 }, { k: "colour", v: "black" }]. Filter with $elemMatch so the key and value match in the same element, and back it with a compound multikey index on attrs.k and attrs.v, usually prefixed by category. Build the alternative too, one field per attribute, and compare index count, index size and query plans.
• Facets with $facet. One aggregation: a $match for the current filters first, then a $facet stage with one sub-pipeline for the page of results, one for price buckets using $bucket, and one per attribute using $unwind and $group for counts. Only the stages before $facet can use an index, so the design question is how much you can narrow in that first $match.
• Index design. Apply the equality, sort, range guideline when ordering compound index fields, check each search with explain("executionStats"), and record documents examined against documents returned.
• Denormalising the vendor. Embed the vendor name and rating in each product (the extended reference pattern) so results need no $lookup, and decide how updates to a vendor's name reach its products.
• Pagination. Compare skip and limit with range-based pagination on a sort key plus _id.

Show your supervisor the schema comparison, the aggregation pipeline, and three explain plans: a collection scan, a poor index, and the index you kept.

How to evaluate it

• Latency: p50 and p95 for five fixed searches at 20,000 and at 200,000 products, with and without your indexes.
• Query plans: documents examined per document returned for each search, from explain output.
• Storage: data and index sizes for the attribute pattern against the fixed-field design.
• Correctness: a test suite that checks facet counts against a brute-force count for 30 random filter combinations.
• Usability: five people find a specific product using filters; record time taken and where they got stuck.

Suggested plan

• Weeks 1 to 2: list the 10 queries the catalogue must serve, pick categories and attributes, write the data generator.
• Weeks 3 to 5: schema, validation rules, vendor product form, seeded data.
• Weeks 6 to 8: search API with $match and $facet, first version of the shopper UI.
• Weeks 9 to 11: indexes, explain plans, the alternative schema, benchmarks.
• Weeks 12 to 15: pagination, polish, usability sessions, report.

Path to a product

Specialist marketplaces with messy attributes are everywhere: second-hand phones, auto parts, textbooks, building materials, handmade goods. A clean catalogue and search engine is the hard part of each. You could offer it to a niche marketplace as a hosted catalogue service, or open source the search module and build a reputation with it. Even without customers, a project that shows schema trade-offs with benchmarks is exactly what backend teams look for.

Scope warning

Do not build checkout, payments, delivery or vendor payouts. A "buy" button that does nothing is fine. Keep categories to six or so and make each one realistic, rather than fifty thin ones.

Learn what you need on Sefism

• MongoDB roadmap: the data modelling, indexes and aggregation stages are the core of this project.
• MongoDB cheat sheet: quick reference for $elemMatch, multikey indexes, the ESR rule and $facet.
• MongoDB Manual: the aggregation stage reference and the data modelling section.
• MongoDB Compass: build the facet pipeline stage by stage and read explain plans visually.
• Mongo Playground: try a $facet stage on ten documents before running it on twenty thousand.
• MongoDB Node.js Driver Documentation: running aggregations and typing collections from your API.
• MongoDB Atlas: a free cluster to host the catalogue, and Atlas Search if you reach the stretch goal.

Get help with this idea

The risk here is spending the semester on a shop front and leaving the schema as whatever came out first. Tauseef can help you pick the queries that drive the design, plan the schema comparison, and set up benchmarks that give your report real evidence. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session