Women’s fashion marketplace

Teloire

A pre-launch marketplace in active development, built around canonical product data, personalized discovery, seller-controlled listings, and server-authoritative checkout and order state.

Context: Independent marketplace product
Role: Full-stack product & architecture
Status: Pre-launch · In development
Stack: Next.js · NestJS · PostgreSQL · Redis · Stripe
Evidence: Source · tests · browser suites · sandbox drills

01 / Product overview

Discovery, selling, and checkout share one source of truth.

Buyer and seller experiences are connected by canonical commerce records—not by cached views or provider responses.

Discover

Build feeds and search sessions from eligible listing projections with deterministic fallback and stable pagination.

Personalized feedsSearch sessionsHard filters

List

Create seller-owned items and listings, validate publication requirements, and emit durable change events.

Seller listingsPublication gatesMedia readiness

Transact

Reserve inventory, calculate authoritative quotes, orchestrate payment, and finalize immutable order records.

ReservationsStripe boundaryOrder lifecycle

02 / Engineering architecture

Canonical writes drive rebuildable experiences.

Next.js clients call a domain-oriented NestJS API. PostgreSQL owns listings, availability, reservations, quotes, orders, and financial records; no search index, cache, browser state, or payment response can redefine that truth.

Transactional outbox workers project listing changes into discovery and run other asynchronous consumers. Stripe calls stay outside database transactions and return trusted evidence for idempotent finalization.

Request path and canonical write boundary

Interface layer

Buyer + seller web

Discovery, listing management, checkout, and order experiences

Next.jsResponsive UIPrivate sessions

Synchronous runtime

NestJS API

Authorization, domain rules, provider orchestration, and authoritative totals

Domain servicesOwnershipIdempotency

Canonical foundation

PostgreSQL

Items, listings, reservations, quotes, orders, financial records, and outbox facts

Row lockingTransactionsDurable truth

Asynchronous and provider boundaries

Separate worker runtime

Outbox consumers

Lease, retry, and project durable listing events without blocking browser requests

PostgreSQL claimsRetriesVersion checks

Rebuildable read side

Discovery projection

Search, ranking inputs, and personalized feeds derived from eligible canonical listings

FTS + trigramDeduplicationStable sessions

External boundary

Stripe

Idempotent payment requests outside transactions; trusted evidence returns for order finalization

Sandbox evidenceReconciliationNo browser authority

Non-canonical support: Redis-backed controls can be lost or rebuilt without changing product, inventory, payment, or order truth.

03 / Engineering highlights

Commerce state stays authoritative under concurrency.

The implementation favors explicit ownership, durable events, and reversible projections over coupling product truth to a provider or cache.

01Featured workflow

Inventory first. Provider calls second.

Checkout locks items in deterministic order, persists a reservation and server-owned quote, calls Stripe outside the transaction, then revalidates trusted payment evidence before atomically creating order truth.

Stable discovery sessions

Resolved intent and ordered results are snapshotted so cursor pages do not silently reparse or reorder a query.

Version-aware projections

Transactional outbox events and version checks prevent delayed asynchronous work from overwriting newer listing state.

Seller publication gates

Owned Item and Listing records must satisfy eligibility, price, size, condition, and ready-media rules before publication.

Deterministic fallback

Optional provider-bounded enrichment can improve retrieval, but core search remains useful when remote AI is disabled or unavailable.

04 / Technical challenges

Decisions that protect marketplace truth.

Canonical versus derived dataPostgreSQL owns business facts; search projections, sessions, Redis controls, and provider responses remain replaceable.
Inventory concurrencyDeterministic row locking and expiring reservations prevent two buyers from completing the same item.
Payment isolationExternal calls stay outside database transactions, while idempotent finalization consumes trusted evidence exactly once.
Search eligibilityExplicit category, size, condition, price, and availability constraints remain hard gates before ranking.
Seller importsExternal seller-platform imports are planned, not verified as implemented; the current evidence supports seller-created canonical listings and APIs.