MMJ EstarProduction Diamond Commerce Platform
The digital arm of a 35-year-old offline jewellery business, engineered as a full production system: quality-gated supplier catalog ingestion, owned 360° media CDN, dual-currency payment rails, and RLS-hardened backend data.
Problem Framing
The mandate was not to ship a "website". It was to make several production subsystems correct at the same time: supplier-media ingestion, quality-gated catalog exposure, dual-currency payments, and policy-backed trust signals tied to real backend state.
The hardest part was infrastructure alignment: mirroring Vision360 turntable media into owned storage, then ensuring token validation recognized manifest-derived child URLs instead of only root media records.
Platform Architecture
FastAPI operates as a BFF boundary that isolates supplier systems and enforces quality/security invariants. PostgreSQL connection pooling and startup cache warming keep hot catalog routes fast under concurrency.
Vision360 Media Pipeline
256-frame supplier turntables are mirrored into owned DigitalOcean Spaces storage. The frontend consumes manifests, never raw supplier CDN URLs, preserving both white-label trust and operational control.
Deployment Evidence (Apr 03, 2026)
The performance and reliability claims below were documented in the production deployment report and runbooks, not reconstructed from memory.
Verification Snapshot
- • Backend tests: 221 passed before rollout.
- • Frontend tests: 207 passed with clean production build.
- • Health endpoints and payment callback paths validated post-deploy.
Latency + UX Corrections
- • Initial page payload reduced from 24 to 12 catalog items.
- • Frame pool increased 6→10 and manifest pool increased 3→6.
- • Aggressive page-2 prefetch moved from 80ms to 3000ms to prevent startup contention.
Backend Decisions (BFF + Pooling)
- • Versioned FastAPI routers split by bounded context (catalog, auth, checkout, payments, orders).
- • ThreadedConnectionPool initialized once on startup and reused across requests.
- • Startup daemon warms default hot catalog + education spin maps (non-fatal if warm fails).
Payment Rails & Webhooks
- • INR domestic flow via Razorpay and USD international flow via Stripe from one checkout surface.
- • Currency routing enforced upstream to prevent Stripe intent mis-currency bugs.
- • Supplier submission moved to BackgroundTask so webhook acknowledgements return immediately.
Security & Data Governance
- • Security headers enforced in middleware: nosniff, DENY frame, strict referrer policy, permissions policy.
- • Row-Level Security lockdown across sensitive tables via migrations.
- • Webhooks verify signatures before any database mutation to defend replay/abuse paths.
Bottlenecks Solved
- • Manifest child token validation mismatch caused poster-only fallback in the 360 viewer.
- • Dual-provider redirect/currency mismatch required unified routing and callback handling.
- • Hot catalog quality gate enforced complete 256-frame assets before storefront exposure.
What Was Built (April 8, 2026)
- • Production FastAPI BFF with connection pooling, secure middleware, health endpoints, and observability routes.
- • Dual-rail payment system (Razorpay INR + Stripe USD) with verified webhook-signature-first processing.
- • 360° viewer for ~1,100 quality-gated diamonds served from owned CDN manifests.
- • Supabase/PostgreSQL schema with 25+ migrations, RLS policies, and realtime publication setup.
- • Playwright auth E2E coverage, lead-event attribution model, and launch gating via coming-soon mode.
Incident Packets & Root-Cause Fixes
- • 360 viewer poster-lock bug: token validation originally matched root media rows only; fix expanded validation to manifest-derived child frame URLs.
- • Dual-rail payment mismatch: currency-routing edge cases caused provider/session drift; fix centralized routing policy and callback handling at the BFF boundary.
- • Checkout acknowledgement delay: supplier submission was coupling webhook response time; fix moved supplier handoff to background tasks after verified payment state mutation.
Outcome
MMJ Estar shipped as a defensible production commerce system: owned media infrastructure, real payment correctness, strict data governance, and transparent customer-facing trust mechanics backed by backend state.