Implement A/B testing with Middleware rewrites and cookies

WHAT THIS TESTS: This question tests whether you understand Next.js Middleware as an edge traffic controller and whether you anticipate the operational side effects that rewriting requests introduces for caching layers and analytics pipelines. It separates seniors who think about the full request lifecycle from those who treat Middleware as a simple redirect helper.

A GOOD ANSWER COVERS: A strong answer walks through four layers in order. First, segmentation logic: on the first visit, Middleware checks for an existing experiment cookie; if absent, it assigns a variant using a deterministic hash or random draw and sets a sticky cookie so the user always sees the same variant. Second, internal rewrite: the Middleware uses NextResponse.rewrite to map the public URL to a variant-specific internal path such as /landing/control or /landing/treatment without changing what the browser shows in the address bar. Third, cache strategy: because the public URL is identical for both variants, a default CDN or Edge cache would serve the same cached response to everyone; the candidate should mention either configuring the cache key to vary on the experiment cookie, using middleware to add a Vary header, or opting the route out of static generation to prevent stale cross-pollination. Fourth, analytics integrity: since the rewrite happens server-side, client-side pageview trackers may not naturally know which variant rendered, so the answer should mention injecting the variant ID into a data layer, server-side GTM push, or HTML meta tag for the analytics script to read.

COMMON WRONG ANSWERS: Red flags include suggesting a client-side redirect or router push to swap variants, which changes the URL and breaks SEO as well as refresh behavior. Another red flag is proposing to store variant state in React Context or localStorage without a server-side sync, because that causes hydration mismatches and flicker. Candidates who say Middleware rewrites automatically handle caching without extra configuration are also wrong; Next.js static optimization and CDN edge caches key off the URL path by default, so two variants behind the same path will collide unless you explicitly vary the key or bypass cache.

LIKELY FOLLOW-UPS: An interviewer might ask how you would handle bot traffic or prefetching, whether you would use the proxy.js convention in the App Router, how to prevent variant flash on hard refresh, or how to scale this to dozens of experiments without ballooning Middleware bundle size. They may also ask how you would measure statistical significance or integrate with a feature flag service.

ONE CONCRETE EXAMPLE: Imagine a landing page at /signup. The Middleware checks for a cookie named exp_2024_landing. If missing, it rolls a number between zero and one; below 0.5 it sets variant A and rewrites to /signup/a, otherwise variant B and rewrites to /signup/b. The /signup/a and /signup/b routes are real pages in your project but are not linked publicly. The Middleware adds a Vary: cookie header so the CDN caches two distinct responses. In the layout for both variants, a server component reads the cookie and renders a script tag that sets window.dataLayer.push with the variant name before the analytics library loads, ensuring every pageview is attributed correctly.