A fashion marketplace that holds up at peak
A multi-seller fashion marketplace built around fast browsing, smart filtering, and a checkout that keeps up with high-volume drops.
The brief, in specifics
- Industry
- E-commerce & Retail
- Duration
- 20 weeks
- Cooperation model
- Fixed price, phased
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The hard problem
Listings from different sellers clashed, filtering rarely returned relevant results, and checkout struggled under peak flash-sale traffic.
Each seller invented their own sizing and attribute names, so a filter for a UK 10 missed most of the catalog and shoppers had learned not to filter. At the other end, checkout decremented stock after creating the payment intent, so during a drop the same unit could be sold several times and the reconciliation happened by refund.
We standardized the seller listing flow, added AI-assisted recommendations and filtering built on real shopping behavior, and hardened checkout for high-traffic drops.
The system we were asked to build
Seller listings were inconsistent and checkout buckled during drops. We standardized the catalog and rebuilt discovery and checkout for scale.
A marketplace with about nine hundred sellers, growing by drops: limited releases that put a season's traffic into ninety seconds. Two of the previous four drops had failed at checkout, publicly, and the brands running them had started asking for guarantees. The engagement covered both halves of that: the catalog that made discovery poor, and the checkout that fell over when discovery worked.
Systems Integration
How the pieces fit
- 01
Standardized seller onboarding and catalog structure
Listings validate against one taxonomy at upload, with vendor size charts converted to a common scale, and an unmappable listing is refused at the door.
- 02
Added AI recommendations trained on browsing and purchase signals
Behavior signals were only usable once the catalog was standardized, so this ran after the taxonomy instead of in parallel with it.
- 03
Rebuilt filtering around the attributes shoppers actually use
Filters were rebuilt on the attributes shoppers actually use, which the standardized catalog made possible. The previous set filtered on fields most listings lacked.
- 04
Load-hardened checkout for flash-sale traffic
Checkout takes an atomic stock reservation before the payment intent, behind a queue that admits at a fixed rate, load-tested against a real drop's traffic shape.
Flash-Sale Resilient Checkout
Engineered to process tens of thousands of concurrent checkouts during high-demand product drops.
Drops put tens of thousands of people on one SKU in the same second. Inventory is decremented in Redis with an atomic reservation before the payment intent is created, so the stock check and the sale can't drift apart, and reservations expire if checkout is abandoned. The queue admits at a fixed rate instead of accepting everyone, and browsing stays fully cached so only the buying path touches origin.
- Atomic Redis reservation before the payment intent
- Expiring holds so abandoned carts release stock
- Rate-admitting queue; browsing served from cache
Operations through the first ten minutes of the Autumn Outerwear drop: 18,402 shoppers, 412 checkouts a minute, and a stage table that accounts for every one of the 8,802 that reached payment, 99.6% of them completed, with stock reserved before any card was charged.
AI-Powered Recommendation Feed
The Maison Revel wide-lapel blazer at £420.00, previewed from the Studio: six of eight photographs live, the measurements every seller now files identically, and a row of pieces other shoppers viewed and bagged with it, read from a slate built overnight.
Personalized product recommendations based on shopper browsing and what gets carted together.
Recommendations are built from viewed-together and carted-together behavior instead of category tags, which is what surfaces the pairing a merchandiser wouldn't have thought to make. The model runs nightly on Lambda and writes a precomputed slate per shopper, so the feed is a lookup at request time. Cold-start shoppers get trending-in-your-size in place of a generic bestseller list.
- Viewed-together and carted-together signals, not category tags
- Nightly precompute; request time is a lookup
- Cold start falls back to trending in your size
Self-Serve Seller Catalog Studio
Standardizes product metadata, sizing, and multi-vendor inventory uploads.
Sellers were each inventing their own sizing and metadata. The studio validates against one taxonomy on upload, converts vendor size charts into a common scale, and refuses a listing that can't be mapped before it can pollute search. Bulk CSV imports are dry-run first and report exactly which rows would fail, so a seller fixes the file instead of the catalog.
- One taxonomy validated at upload; unmappable listings refused
- Vendor size charts converted to a common scale
- Dry-run bulk imports that report failing rows before writing
The seller's listing quality screen: 71 of 84 listings ready, six needing work and seven blocked, each row naming what is missing and how the label's own size was converted, beside a dry-run import that lists the rows it would refuse before writing anything.
Phase by phase
Phase 1: Catalog & Drop Concurrency Audit
Marketplace Infrastructure Analysis
Audited seller catalog inconsistencies and flash-sale traffic spikes causing checkout bottlenecks during high-demand releases.
- Catalog Standardization Spec
- Traffic Spike Audit
- Marketplace UX Benchmark
Phase 2: Recommendation & Search Engine
AI Personalization & Algolia Search
Standardized seller product attributes and integrated AI recommendations trained on shopper browsing behavior and purchase history.
- Standardized Catalog Schema
- Algolia Search Layer
- Recommendation Engine
Phase 3: High-Traffic Checkout Hardening
Serverless Scale & Stripe Connect
Hardened checkout pipeline with AWS Lambda auto-scaling and Redis queueing for high-volume drops across multi-seller carts.
- Flash-Sale Checkout Pipeline
- Stripe Connect Engine
- Concurrency Test Suite
Phase 4: Seller Onboarding & Drop Launch
Multi-Seller Rollout & Peak Performance
Rolled out updated marketplace platform to 150+ sellers ahead of peak holiday drop season, logging 99.6% checkout success.
- Seller Studio Tools
- Drop Performance Dashboard
- Production Sign-off
One bag, six pieces, four sellers: £2,270.00 of goods plus £18.00 delivery, every piece reserved before payment, and the panel that splits the goods into the £785.00, £935.00, £310.00 and £240.00 each seller is separately paid.
What it carries now
99.6%
Peak checkout success
+24%
Add-to-cart rate
−55%
Seller onboarding time
Peak checkout success is completed orders over attempted orders during drops specifically, not across all trading. Add-to-cart is measured per session on the browse surfaces the recommendations changed. Seller onboarding time is from account creation to first published listing, median across sellers onboarded after launch.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
What the architecture settled
Flash-sale checkout hardening achieved 99.6% transaction success during high-volume drops.
The success rate came from reserving before charging, not from more capacity: the old order of operations would have failed at any scale, just less visibly.
AI product recommendations quietly lifted add-to-cart rate by +24%.
Recommendations worked because they were quiet: placed where a shopper was already browsing, never interrupting, which is why the lift showed up in add-to-cart and not in clicks.
Standardizing seller catalog onboarding cut seller setup time by 55%.
Onboarding halved because the dry-run import reports failing rows before writing: sellers used to fix a catalog when they could have fixed a spreadsheet.
How the work was run
A cross-functional team of 5 worked on a fixed price, phased basis over 20 weeks, covering Marketplace platform, Search & recommendations, Checkout. We ran a standing mid-week checkpoint and written decisions in place of status meetings. Nothing shipped without a live demo first.
The catalog work went to the top forty sellers first, with the team sitting in on their listing process, because sellers route around a taxonomy imposed without that. Checkout was rebuilt against a load harness that replayed a real drop's traffic shape instead of a flat curve: the failure mode was always the spike, never the volume.
One listing, one standard
A listing that can't be mapped is refused, and the seller is told exactly why.
Three of Maison Revel’s listings as they were filed: one ready, one short of photographs, and the coat the standard held back from the drop. Switch fields off and on to see what makes a listing ready, what only needs work and what blocks it. Use the arrow keys once a tab is focused.
Filed in full. Switch a field to Missing or Filed, or change the photograph count.
- Photographsunder 4 blocks · under 8 needs work8 of 8
- Category in the taxonomyblocks“Coats” mapped
- Size on the common scaleblocks“M” → EU 38 · UK 10
- Garment measurementsblocksChest, shoulder, sleeve, length
- Fabric compositionneeds workFiled
- Color on the standard paletteneeds work“Camel”
- Care instructionsneeds workFiled
- Every field the standard asks for is filed.
- On the shop and in dropsYes
- Found by the EU 38 · UK 10 filterYes
- In search, ranked at 0.92Yes
Why a listing is refused instead of let through: a filter for a UK 10 used to miss most of the catalog because each seller named sizes their own way. A listing that can't be mapped would put that back, so the standard stops it at upload and says exactly what's missing.
From a drop opening to an order every seller is paid for
The old checkout created the payment intent first and took the stock afterward, so during a drop one unit could be sold several times and reconciled by refund. The order is now the other way around, proved against a load harness that replayed a real drop’s traffic shape instead of a flat curve.
- 01 · TriggerA drop opensA season's traffic arrives in ninety seconds. Browsing stays fully cached, so only the buying path touches origin.
- 02 · QueueRate-admitting queueShoppers are admitted onto the buying path at a fixed rate, never all at once, on AWS Lambda capacity that scales out.
- 03 · EngineAtomic stock reservationInventory is decremented in Redis in one atomic step before the payment intent exists, so the stock check and the sale can't drift apart.
- 04 · StateExpiring holdsA reservation that isn't paid for expires and its unit goes back on sale, so an abandoned checkout never strands stock.
- 05 · DeliveryMulti-seller paymentOne charge for a bag filled by several sellers, split through Stripe Connect so each seller is paid for their own pieces.
What a brand running a drop needs to know
Drop integrity: no overselling, no stranded stock
Nobody is charged for stock that isn't held
The unit is reserved atomically before the payment intent is created, so the stock check and the sale can't drift apart and nothing is reconciled by refund afterward.
Abandoned checkouts give stock back
Reservations expire when a checkout is abandoned, so a shopper who walks away mid-drop doesn't quietly take a piece off sale for everyone else.
Tested against the spike, not the average
Checkout was rebuilt against a load harness replaying a real drop's traffic shape, behind a queue that admits at a fixed rate, because the failure was always the spike.
Running limited drops across hundreds of sellers? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsA checkout that stopped losing sales to a 6-second load
Profiling found the real bottleneck behind a slow checkout (an N+1 query and an oversized bundle) and tuned both, with before-and-after metrics locked in as a baseline against future regressions.
E-commerce & Retail · 5 weeks
Web PlatformsA reader people finish, and a library that remembers where they stopped
A reading platform for a comics catalog: a browse surface people can actually navigate, a reader that gets out of the way, and a history that puts everyone back on the page they left.
E-commerce & Retail · 18 weeks
Web PlatformsOne number, a whole handset, and a database that keeps up with 125 brands
A metered IMEI lookup service that turns fifteen digits into a device, its specifications and its status. It's sold three ways to three audiences and backed by a device database that maintains itself.
Consumer Electronics · 22 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
