MMJ EstarDiamond Commerce Platform
The digital arm of Mangal Murti Jeweller, a family jewellery business (Ayush's brother's), built as a full-stack system: quality-gated supplier catalog ingestion, owned 360° media CDN, dual-currency payment rails, and RLS-hardened backend data. The build is complete and the site is launching; the public domain still shows a coming-soon page until launch.
Problem Framing
The mandate was not to ship a "website". It was to make several 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 figures below come from my deployment report and runbooks. Those documents are private, so treat the figures as self-reported.
Verification Snapshot
- • Backend tests: 221 passed before rollout.
- • Frontend tests: 207 passed with a clean 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)
- • 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 is built as a defensible commerce system: owned media infrastructure, real payment correctness, strict data governance, and transparent customer-facing trust mechanics backed by backend state. The site is launching; the public domain still shows a coming-soon page until launch.