Describe middleware.js.

We want to protect our /dashboard route. If a user doesn't have a specific session cookie, how would you use middleware.js to redirect them to /login?

You write some code in middleware.js to read a local JSON config file using Node's fs module, but it crashes on startup. Why is this happening, and how would you fix it?

We noticed our middleware is running on every single static asset request, like images and CSS, which is slowing down page loads. How would you configure it to only run on specific API and page routes?

We are rolling out an A/B test. We want to bucket users based on a cookie and rewrite their request to either /version-a or /version-b under the hood without changing the URL in the browser. How would you implement this in middleware, and how do you ensure it doesn't break CDN caching?

A developer on your team added a redirect in middleware.js from / to /welcome, but now the browser throws a 'Too many redirects' error. What's causing this infinite loop, and how do you debug and resolve it?

We need to detect a user's country to redirect them to a localized path like /fr for France. How would you leverage Next.js middleware and the incoming request object to do this efficiently without hitting an external IP lookup API?

We are designing a global application. We need to decide whether to validate JWTs inside middleware.js at the Edge, or defer validation to individual Server Components or API routes. What are the latency, security, and database connection tradeoffs of both approaches?

Your team wants to integrate a third-party security/logging SDK inside middleware.js. However, the SDK relies on Node.js built-ins and exceeds the Edge runtime's size limits. How would you architect a solution to still intercept requests without bloating or breaking the middleware?

We need to implement basic IP-based rate limiting for our API routes. If we use middleware.js connected to an external Upstash Redis instance, what happens to our global latency if the Redis instance experiences a spike in response times? How would you design this to fail-safe?

We are migrating a massive legacy monolith into a Next.js multi-zone architecture with multiple independent Next.js apps. How do you handle global routing, authentication, and shared headers across these zones using middleware? Would you use a single root middleware, or delegate to zone-specific middlewares, and why?

We currently use an Nginx reverse proxy layer for routing, basic auth, and header injection. The product team wants to migrate these responsibilities into Next.js middleware.js to give frontend developers more control. What are the architectural risks, performance implications, and operational tradeoffs of moving this logic from the infrastructure layer to the application layer?