Skyxis

Problem — A guest's cart and wishlist need to survive a page refresh, then merge cleanly into their account the instant they log in — without silently dropping items from either side.

Approach — Cart and wishlist persist client-side for guests and merge into the server-side cart on login as a union of both, not an overwrite, so nothing gets lost in either direction.

Problem — "In Stock" and "Only N left" badges are read at listing time, but inventory can change by the time someone reaches checkout — a stale badge shouldn't let someone pay for something that's already gone, and with a wide catalog checking out concurrently, holding a database lock per checkout doesn't scale the way it does on a single hot event.

Approach — Inventory is re-checked at checkout with optimistic locking — a version field on the stock row — rather than trusted from the listing page or held behind a pessimistic lock: went optimistic here, not pessimistic like a single flash-sale item, because carts across hundreds of different SKUs rarely contend for the same row, so a lock held for the checkout window would cost more than the rare retry does. Holds correct under 100+ concurrent checkouts across the catalog.

Problem — Price, discount percentage, and active promo codes need to agree across listing, cart, and checkout — a client-computed price drifts the moment a promo or discount changes, and recomputing pricing from MongoDB on every listing page view adds latency for data that changes rarely.

Approach — Pricing is computed server-side (base price, discount, active promo) and cached in Redis in front of the catalog, invalidated the moment a price or stock level changes, so listing pages stay fast without ever serving a price the client had to calculate itself.

Problem — Doing order confirmation, inventory write-down, and the email receipt inline in the checkout request makes the customer wait on work that isn't their payment.

Approach — Checkout publishes an "order placed" event to RabbitMQ the moment payment clears and returns immediately; a fulfillment consumer handles the email and downstream bookkeeping, so checkout latency isn't tied to how long the email provider takes to respond.