Fix the design · Incident triage

Hydration Crash: The Product Page That Broke on Launch Day

On Nykaa’s beauty-sale launch day, server HTML and browser JavaScript disagreed on cart state — hydration errors hit about 18% of sessions, and about 8% of users saw a white screen.

You are on Nykaa’s product-page team on launch day. Traffic jumps about 4×. Server HTML and client JavaScript disagree on cart state — about 18% of sessions hit hydration errors.

We need your help. Identify the bottlenecks and failure modes in the current design, then redesign the path from “server HTML” → “interactive product page” so cart state has one source of truth, third-party widgets cannot break hydration, and a mismatch cannot white-screen the launch.

Problem

Redesign Nykaa’s existing product-page render path — it already server-renders HTML for a fast first paint, then hydrates the same page in the browser including the cart badge.

Incident summary

  • Launch traffic drove about 4× visits to the new product pages.
  • Hydration errors hit about 18% of sessions within 20 minutes.
  • About 8% of users saw a white screen after the error boundary tried to recover.
  • In about 34% of logged repros, the cart badge count differed between server HTML and the first client paint.
  • Largest Contentful Paint rose from about 2.1s to about 3.8s at p75. Support tickets for “Add to cart broken” spiked about 6× while the payment API stayed healthy.

Assumptions made by the team

  • Server HTML always matches what the browser draws on first paint.
  • Reading the cart from localStorage is fine — users are logged in anyway.
  • Hiding hydration warnings on the badge is a permanent fix, not a band-aid.
  • Third-party widgets will hydrate cleanly if we lazy-load them.
  • Remounting the whole page after an error is acceptable during launch.

Impacted services

  • Product page (critical) — Hydration errors in about 18% of sessions.
  • Cart badge (critical) — Server and browser counts disagreed on first paint.
  • Error boundary (degraded) — Recovery remounted the page and caused white screens for about 8% of users.
  • Payment API (healthy) — Stayed successful — broken sessions never reached add-to-cart.
  • Customers (critical) — Add-to-cart support tickets spiked about 6×.

Triage questions

  1. Where does server-rendered HTML disagree with what the browser renders first?
  2. How would you redesign the product page so cart state cannot mismatch between server and client?
  3. Should third-party widgets like reviews be rendered on the server, the client only, or both?
  4. What would you monitor in the browser to catch this before support floods?

← All design challenges

Loading scenario…