STDNT GEAR

The vendor API returns thousands of products with nested variants, prices, stock, and colour swatches. Naively inserting everything concurrently caused PostgreSQL deadlocks under load, and a single failed record could kill the whole sync.

• Single-threaded sequential inserts — safe but far too slow for a full catalogue refresh.
• High concurrency (10+ parallel batches) — fast, but frequent deadlocks on shared indexes.
• Smart batching with capped concurrency and per-operation retry.

Grouped products into batches of 50 (partitioned to reduce key overlap), capped concurrency at 2 in-flight batches, and wrapped every write in deadlock-aware retry with exponential backoff.

A full catalogue sync is slower than it could theoretically be, but it runs unattended and self-heals from transient PostgreSQL deadlocks instead of failing the whole job.

Quotes and invoices involve price adjustments (staff discounts, corrections). If a client ever computed or held the authoritative total, a tampered request could change what a customer owes.

• Trust the price the client submits with the quote.
• Recompute and lock the total server-side whenever a quote is priced or converted to an invoice.

Every quote total is calculated and locked server-side. Staff-applied adjustments are stored as discrete line items, not baked into a single mutable total, so invoice history stays auditable.

More server-side computation and stricter API contracts, in exchange for pricing integrity that can't be bypassed from the client.

Category trees and multi-facet product filters (brand, gender, material, fit, price) get slow at scale if every filter click hits PostgreSQL with fresh joins.

• No caching — simplest, but filter interactions get sluggish as the catalogue grows.
• Cache everything in Redis from day one.
• Layer caches by volatility: in-memory for near-static data, React Query for per-user UI state, Redis reserved for cross-instance needs.

Cache the category hierarchy in server memory with TTL + explicit invalidation on writes, run facet-count queries in parallel rather than sequentially, and let React Query handle client-side staleness.

In-memory cache doesn't survive a restart or share state across multiple server instances — acceptable for current scale, with Redis already integrated as the upgrade path.