The problem
Discovery is a deceptively hard problem. Someone opening a local marketplace wants a short, relevant, correctly ordered list of what is near them, and they want it before they lose patience. Everything else about the product is secondary to getting that first response right.
That constraint shaped the architecture. Proximity queries are the hottest path in the system, they run on every session, and they get slower as the catalogue grows. Designing for that from the beginning was cheaper than retrofitting it later.
What I built
I worked across the whole stack. On the backend, a Node.js and Express service exposing a REST API, with request validation at the boundary and consistent error semantics so the client never had to guess what a failure meant.
Marketplaces are really three systems wearing one coat: a catalogue, an identity and permissions layer, and a transaction flow. Keeping those boundaries clear in the API meant that changing how sellers are onboarded did not require touching how listings are searched.
MongoDB holds the catalogue and user data. Document storage suits listings well, since sellers across different categories carry genuinely different attributes, and forcing them into one relational shape would have meant either a sparse table or a join for every read.
On the frontend, an Angular application consumes that API, kept deliberately thin, with the business rules living in the service where they can be tested properly and changed once.
Running it in production
Serving ten thousand users is less about raw throughput than about the long tail: the slow query that only appears with real data distribution, the third-party call that hangs instead of failing, the deployment that needs to roll back at nine on a Friday evening.
Most of the engineering effort after launch went into finding those, fixing them, and adding the logging that made the next one faster to find than the last.