Questions
18 of 33
1Explain server-side rendering (SSR) in Next.js.
2List the benefits of Server-Side Rendering in Next.js.
3What are server components?
4How to use server components in next js?
5What is the React Server Component Payload (RSC)?
6Describe how server components are rendered.
7Describe server rendering strategies
8How can you keep Server-only Code out of the Client Environment
9What are the issues of using context provider at the root of the application?
10List dynamic functions available to server components.
11List all Dynamic APIs.
12How do we opt for Static Rendering, Dynamic Rendering and Streaming?
13Explain the difference between SSR, SSG, ISR, and CSR in Next.js. When would you choose each?
14How does getServerSideProps work internally? What is its execution context?
15What are the performance trade-offs of SSR vs SSG in a high-traffic production app?
16How does Next.js handle hydration? What is a hydration mismatch, and how do you debug it?
17What happens when getServerSideProps throws an error? How do you handle it gracefully?
18How would you architect a Next.js app that needs both personalised (SSR) and cacheable (SSG) pages at scale?
19Explain the App Router vs Pages Router SSR model differences. How does React Server Components change the SSR paradigm?
20How do React Server Components (RSC) differ from traditional SSR? Can they be used together?
21How does streaming SSR work in Next.js 13+? What role does Suspense play?
22How would you implement partial hydration or Islands Architecture in Next.js?
23Explain how Next.js handles data fetching waterfall problems in SSR and how you'd mitigate them.
24How would you implement partial hydration or Islands Architecture in Next.js?
25How do you implement caching strategies for SSR responses in Next.js? (CDN, Cache-Control, stale-while-revalidate)
26How would you reduce TTFB (Time to First Byte) in an SSR-heavy Next.js app?
27What's the difference between fetch caching in the App Router vs traditional getServerSideProps?
28How do you avoid redundant database/API calls across multiple server components on the same page?
29How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?
30How do you prevent sensitive server-side data from leaking to the client bundle?
31How would you implement role-based rendering on the server without exposing protected routes to the client?
32How do you debug SSR-only issues that don't appear in local development?
33How can we control dynamic rendering behaviour in next js?
nextjsnextjs
Basics
Project Structure
Runtime
Compiler
SSG
SSR
CSR
Routing
Route Handlers
Route Groups
Dynamic Routes
Parallel Routes
Intercepting Routes
Middleware
Server Actions
APIS
Data Fetching
Caching
Clients
Optimisation
i18n
Security
Architecture
Deployment
Accessibility
18 / 33

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

Difficulty: 7/10
SSR, SSG, caching

Architect a hybrid Next.js app using route segmentation, with SSG for public content (CDN-cached) and SSR for personalized routes, sharing common components and data fetching logic through a monorepo structure

Building a Next.js application that handles both high-scale cacheable content and personalized user-specific pages requires a deliberate architectural split. The key insight is that these different page types have opposing infrastructure needs—SSG pages benefit from CDN distribution and zero origin load, while SSR pages require compute per request and often need to access user context. By clearly separating these concerns at the routing level, implementing appropriate caching strategies for each, and sharing common code through a well-organized monorepo, you can build a system that scales efficiently while providing personalized experiences where needed.

Architecture Overview: Route-Based Separation
Core Architectural Principles
  1. 1

    Route segmentation: Use route groups to separate public/marketing pages (SSG/ISR) from authenticated/app pages (SSR) at the folder level, allowing different caching strategies per segment.

  2. 2

    Shared component library: Maintain a common UI component library for elements like headers, footers, and cards that appear in both sections, ensuring design consistency.

  3. 3

    Data layer abstraction: Create a unified data fetching layer that can work in both static (build-time) and dynamic (request-time) contexts, with appropriate caching directives.

  4. 4

    Authentication boundary: Place authentication checks in middleware or layout components that only apply to protected routes, keeping public routes completely cacheable.

  5. 5

    CDN strategy: Configure CDN to cache public routes aggressively (hours/days) while bypassing cache for personalized routes or setting very short TTLs.

Route Group Structure for Hybrid Apps

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.

Caching Configuration Example
Data Fetching Layer Abstraction
  1. 1

    Create a unified data layer that works in both static and dynamic contexts: functions that accept options for caching strategy, revalidation, and tags.

  2. 2

    For static contexts (build time), use force-cache to avoid repeated API calls across pages.

  3. 3

    For dynamic contexts (request time), allow passing of user context and use no-store when needed.

  4. 4

    Implement tags for on-demand revalidation that work across both static and dynamic pages.

  5. 5

    Use the same data functions in both marketing pages (ISR) and authenticated pages (SSR) by passing appropriate options.

Unified Data Layer Implementation

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.

Authentication Flow for Hybrid Apps
Build and Deployment Strategy
  1. 1

    Use monorepo tooling (Turborepo, Nx) to manage shared packages across marketing and app sections, enabling efficient builds and dependency management.

  2. 2

    Configure separate build pipelines for marketing and app sections if they have different update frequencies—marketing might rebuild daily, while app deploys per commit.

  3. 3

    Deploy to platforms with good ISR support like Vercel, which handles the complexity of background regeneration and cache invalidation across both static and dynamic routes.

  4. 4

    Set up on-demand revalidation webhooks for marketing content that trigger only when CMS content changes, avoiding unnecessary rebuilds.

  5. 5

    Monitor cache hit rates and SSR response times separately for each route segment to identify bottlenecks.

Complete Page Example: Marketing (ISR) vs App (SSR)

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.

Scenario Questions

0-2 years experience

  1. 1You need a product page that shows a user‑specific discount. How would you set up that page in Next.js so the discount is rendered per user while the rest of the page stays static?
  2. 2If you mistakenly use getStaticProps for a page that requires authentication, what will the user see and why?
  3. 3How would you configure a dynamic route so that anonymous visitors get a statically generated version but logged‑in users get server‑side rendering?

2-5 years experience

  1. 1Our blog has free posts and premium posts behind a paywall. Walk me through how you would fetch data so free posts are served via SSG and premium posts via SSR without duplicating code.
  2. 2After deploying a new personalized dashboard, you notice the SSR endpoint is hitting the database on every request, causing latency spikes. What steps would you take to diagnose and reduce the load?
  3. 3Explain the trade‑offs between using Incremental Static Regeneration versus per‑request SSR for a user‑specific analytics page.

5-8 years experience

  1. 1Design a caching strategy for personalized SSR pages that can be shared across edge nodes while still respecting user privacy. Which headers, cookies, or token mechanisms would you employ?
  2. 2At scale, how would you orchestrate the build and deployment pipelines to generate static pages for millions of product IDs while also supporting on‑demand SSR for newly added items?
  3. 3What are the implications of placing authentication checks in Next.js middleware before deciding between SSR and SSG, and how does that affect latency and CDN caching?

8+ years experience

  1. 1Our organization is migrating a legacy monolith to Next.js and must serve SEO‑friendly static pages alongside highly personalized dashboards. Describe the overall architecture—including data layer, edge caching, and CI/CD—that supports this hybrid model and future feature teams.
  2. 2If multiple product teams need to add their own personalized pages, how would you establish shared conventions and libraries to keep SSR/SSG decisions consistent and avoid cache fragmentation?
  3. 3Regulatory compliance now requires that any personalized data never be cached at edge locations. How would you adapt your Next.js architecture to enforce this while still maximizing cache hit rates for static content?

Follow-up Questions

  • What would you change if the personalization data is stored in a third‑party API?
  • How does your approach affect SEO and first‑byte time?
  • Can you describe how you would monitor cache hit rates for both SSR and SSG pages?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.