Classifieds Marketplace System Design

The interviewer's prompt sounds like a weekend project: "Design a local classifieds marketplace like Craigslist or OfferUp. Sellers post items for sale with photos and a location; buyers browse and search for things near them, and message the seller to arrange a meetup. Money changes hands in person, not through us. Assume the US and tens of millions of users."

The first version writes itself: a listings table, a WHERE title LIKE '%bike%' search, and an image upload field. It runs, and it falls over on contact with real users. Maya, in Austin, posts a used Trek road bike for $450 with six photos at 7:40 on a Sunday evening, inside the busiest posting hour of the week. The photos carry the GPS coordinates of the seller's front door. Daniel, four miles away, searches for "road bike" twelve minutes later and needs to see it, ranked near the top, and not buried under the same scooter reposted in thirty cities. When Daniel taps "Is this still available?", Maya should get the message within seconds, without either of them handing a stranger a phone number. And within the hour, someone will message Maya asking the seller to "prove you're real" by reading back a six-digit code. That is a scam, and the platform has to notice.

The Trap Built Into "Post an Item, Search for Items"

Two failures come up again and again:

• The CRUD App With a Search Box: one database for everything, search as a LIKE query plus a distance filter, photos stored as blobs through the API servers. Signal: never did the arithmetic that shows 10,500 searches a second at peak, 20 TB of new photos a day, and a search index that has to be fresh within a minute.
• The Marketplace Without Trust: a clean, scalable design that treats spam, prohibited items and scams as "we'd add moderation later." Signal: has never watched a marketplace die. The board fills with reposts and scams, and buyers stop coming back.

The passing answer treats the problem as what it is: a two-sided local marketplace with four forces (supply, discovery, conversation and trust), each with its own numbers. Writes are tiny, so one Postgres primary holds the listings. Search is the compute problem, so a geo-routed Elasticsearch cluster answers Daniel's query from the one shard that holds Austin instead of fanning out to all of them. Photos are the byte problem, so they go straight from the phone to object storage, get their EXIF stripped and are served from a CDN. A transactional outbox makes every listing change reach the index in seconds without dual writes. And an automated trust-and-safety gate holds the suspicious 2% for human review, so nobody has to read all 2 million listings a day.