E-commerce marketplace

Overview

A marketplace lives or dies on whether buyers can find things and trust that they’ll arrive. That meant three capabilities that are often built as separate systems — search, catalogue, and delivery logistics — had to behave like a single, coherent product. I architected and built it end to end.

Problem

The trap with a marketplace is treating it as a CRUD app with a search box bolted on. In reality, search is the product: if relevance is poor, the catalogue might as well be empty. And logistics isn’t an afterthought either — where buyers have specific delivery expectations, “when and how does this arrive” is part of the buying decision, not a post-checkout detail. The three had to be designed together.

Solution

An end-to-end marketplace with catalogue, search and delivery integrated as one flow. Search runs on Elasticsearch so relevance and speed are first-class rather than emergent; the catalogue and marketplace logic are served by the application backend; and delivery-service integrations make fulfilment part of the product surface. It launched and operates in production.

Architecture

This was a polyglot system by circumstance and by choice — Ruby on Rails and Laravel on the backend, a TypeScript/Vue.js frontend, Elasticsearch for search, all containerized with Docker. Rather than pretend a marketplace is one uniform thing, the design leaned into clear service boundaries: the search subsystem, the catalogue/marketplace core, and the logistics integrations each had their own responsibilities and contracts.

Elasticsearch sits alongside the primary datastore as a purpose-built read model for discovery. Keeping it in sync — indexing catalogue changes promptly so search never shows stale inventory — is the kind of detail that’s invisible when it works and glaring when it doesn’t.

Technical challenges

Search relevance is a moving target: the “right” ordering depends on the catalogue, the query, and what buyers actually click, and it needs tuning rather than a one-time setup. Building the indexing pipeline so the search view stayed consistent with the catalogue under constant change was the recurring engineering work.

Integrating external delivery services brought the usual reality of third-party systems — differing data models, availability you don’t control, failure modes you have to design around so a courier’s outage never becomes a checkout outage.

Lessons learned

Decide what your product’s core loop is and build everything else in service of it. Here the loop was find → trust → buy → receive, and every architectural choice — a dedicated search index, first-class logistics integration — was justified by whether it made that loop tighter. A marketplace that’s merely a catalogue with search is a catalogue; the value is in making the whole loop feel like one thing.