Vessel Supply Co.

Mobile application

The challenge

Vessel's platform was a single Rails monolith where a catalog import could and did take down checkout. The previous Black Friday, the site degraded for 3 hours 40 minutes at peak, costing an estimated $840K in lost orders. Beyond the outage, conversion was quietly poor: 68% of sessions that reached checkout never completed it, and the team had no instrumentation to explain why.

Research

• Session-replay analysis of 2,000 abandoned checkouts
• Load modeling against three years of traffic data including two Black Fridays
• Dependency mapping of the monolith to identify true service boundaries
• Competitive teardown of eleven DTC checkout flows

The solution

We decomposed along failure domains rather than along code structure — the question was not 'what is a logical module' but 'what must never take down checkout.' Catalog and search moved behind an edge cache where a stale product description is acceptable. Checkout became an isolated service with its own database, scaling policy, and load-shedding behavior: under extreme load it sheds browse traffic to protect payment. Inventory got true reservation semantics, ending the oversell problem that had been generating 200+ support tickets monthly.

UX decisions

Features

• Edge-cached catalog with sub-200ms global TTFB
• Faceted search with typo tolerance and synonym management
• Single-page checkout with wallet and saved-method support
• True inventory reservation with configurable hold windows
• Split-shipment fulfillment across three distribution centers
• Wholesale channel with account-specific pricing tiers
• Mobile app sharing the checkout and catalog services

Technology

Architecture

Next.js storefront renders at the edge with ISR for catalog pages, so product updates propagate in seconds without a rebuild. Node services for catalog, search, cart, and checkout each own their data and communicate over an internal event bus. Elasticsearch powers faceted search; Redis handles cart state and inventory reservations with TTL-based release. Checkout runs in its own GKE node pool with dedicated autoscaling — under load-shed conditions browse traffic degrades to cached responses while checkout retains full capacity. Every service ships independently through GitHub Actions.

Results

The following Black Friday drove 40× baseline traffic with zero degraded minutes in checkout — the browse tier shed load twice as designed, which no customer reported noticing. Conversion rose 34% after the checkout rebuild, worth roughly $6.2M annualized at then-current traffic. Global TTFB dropped from 1.4s to 180ms at p75. Deploy frequency went from biweekly releases to 47 per week.

Lessons learned

1. 01Decomposing by failure domain rather than by domain model was the single highest-leverage decision. The 'correct' DDD boundaries would have left checkout coupled to catalog.
2. 02Load shedding needed to be designed and rehearsed, not configured. Our first game day revealed the shed threshold triggered too late to protect anything.
3. 03The scarcity-badge decision cost us a conversion lift we could measure and a brand cost we couldn't. Vessel's leadership was right to overrule the A/B result.