How would you architect a Next.js app that needs both personalised (SSR) and cacheable (SSG) pages at scale?

For marketing routes (SSG/ISR), implement aggressive CDN caching with Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400. This ensures pages are served from edge locations for an hour, with background revalidation. For product pages or blog posts, use ISR with on-demand revalidation via webhooks when content changes. For authenticated routes, use SSR with minimal caching—perhaps 1-5 minutes at the CDN level if the content isn't highly sensitive, or private, no-cache for truly personalized data. The key is matching the caching strategy to the content's personalization level and update frequency.

Handle authentication at the middleware level for route protection, but defer user data fetching to the page/layout level. This keeps middleware fast (edge runtime) while allowing personalized pages to access full user context. For public routes, middleware simply passes through. For protected routes, middleware verifies the session and redirects if needed. The actual user data can then be fetched in the layout or page using a server-side auth utility that reads the session cookie. This separation ensures public routes remain fully cacheable while protected routes can access user context.

Consider an e-commerce platform with both public product pages (need SEO, cacheable) and user dashboards (personalized, dynamic). Product pages use ISR with on-demand revalidation when inventory or prices change—served from CDN edge, 50ms TTFB, 99.9% cache hit rate. User dashboards use SSR with user-specific data, served from origin with 200ms TTFB but personalized content. Both share the same product data layer, checkout components, and UI library through a monorepo. The result: marketing pages scale infinitely with zero origin load during traffic spikes, while authenticated sections provide personalized experiences with predictable server costs.