Public and stable
Product copy, imagery, structured data, navigation, and most layout.
Lesson 09 · Course capstone
Design a hybrid rendering system
Estimated time: about 20 minutes
The senior interview move is not naming a winner. It is decomposing one product into cache, render, delivery, and client-execution decisions—then defending the seams with evidence.
The case: a global commerce product
Design product pages and checkout entry for a catalog with millions of URLs. Product copy changes weekly; price and inventory change by market within seconds; recommendations may be slow; the cart is private; image galleries and add-to-cart are interactive. Search visibility, mobile performance, resilience, and operational cost matter.
Public and volatile
Market-specific price, availability, promotions, and recommendation results.
Private and interactive
Cart, account state, optimistic controls, and analytics consent.
Compose from constraints
Select product requirements. The generated proposal is a starting hypothesis; your job is to explain every boundary and risk.
One defensible architecture
| Region | Policy | Why | Guardrail |
|---|---|---|---|
| Product shell | Build/on-demand pre-render, CDN cache, tag invalidation | High reuse, indexable, weekly change | Fallback for uncached pages; purge on publication |
| Price + inventory | Request-aware server region or short keyed cache | Market-specific, volatile, correctness-sensitive | Explicit market key; conservative stale policy |
| Recommendations | Parallel read behind a streamed boundary | Optional and independently valuable | Timeout, local fallback, no shell dependency |
| Gallery | Small client entry or island | Gesture and local presentation state | Usable images before hydration; measured JS budget |
| Add to cart | Client control + authorized server mutation | Optimistic interaction with private write | Idempotency, rollback, validation, pending state |
| Cart/account | Private request-aware region | User-specific and sensitive | Never shared-cache; authorize every read and write |
Answer in a repeatable sequence
- Clarify: user journeys, freshness, personalization, indexability, traffic shape, devices, and failure tolerance.
- Partition: stable/volatile, public/private, critical/optional, static/interactive.
- Assign four policies: generation timing, cache policy, delivery/reveal, and client execution.
- Draw data flow: keys, invalidation events, serialized values, mutations, and authorization.
- Name failure semantics: timeouts, stale behavior, fallbacks, retries, and response status.
- Budget and verify: latency, JavaScript, origin work, cache hit ratio, vitals, correctness, and cost.
Handle interviewer pressure
“Why not SSR everything?”
It simplifies freshness but couples stable content to origin capacity and loses public cache reuse. Reserve request work for volatile or private regions.
“Why not make it static?”
Static output fits the catalog shell, not seconds-fresh market inventory or a private cart. Split those policies instead of weakening correctness.
“Why RSC?”
It can keep data access and heavy transforms outside the client graph while composing small interactive entries. It does not choose caching or streaming for us.
“What fails first?”
Cache-key mistakes threaten privacy; dependency waterfalls threaten latency; invalidation gaps threaten freshness; broad client boundaries threaten mobile responsiveness.
Architecture drill
Scenario: The interviewer asks for one rendering mode for the entire product page. Which response demonstrates the strongest architectural judgment?
Choose first. Then deliver your answer in Clarify → Partition → Policies → Failures → Verification order.
Final retrieval practice
What four independent policies replace a single rendering label?
Generation timing, cache/freshness, delivery/reveal, and client execution/hydration.
Where are the highest-risk boundaries in this case?
Public versus private cache keys, stale versus correctness-sensitive data, shell versus optional failures, and server versus client serialization.
What would you draw on a whiteboard?
Page regions, request and cache paths, keys and invalidation events, stream boundaries, client entries, mutations, and observability signals.
How do you finish the answer?
State assumptions, the largest risks, the evidence that would change the design, and a staged rollout with measurable success and rollback criteria.
A complete two-minute answer
“I would not choose one mode for the route. I’d partition it by freshness, privacy, criticality, and interactivity. The public product shell is pre-rendered and CDN-cached with event invalidation; market price and inventory use a request-aware or short keyed cache; the cart stays private.”
“I’d start independent reads in parallel and stream optional recommendations behind a stable fallback and timeout. Database access and formatting remain in the server graph; gallery and cart controls are narrow client entries with progressive HTML behavior.”
“The main risks are cache-key leakage, stale availability, server waterfalls, status semantics after streaming, and mobile main-thread work. I’d correlate field vitals and navigation traces with cache/origin spans, test freshness and authorization, canary the route, and keep a rollback path.”
Course synthesis
- web.dev: Rendering on the Web — framework-neutral rendering tradeoffs.
- React: Streaming server rendering — delivery and failure mechanics.
- Next.js: Incremental Static Regeneration — regeneration and invalidation behavior.
- Astro: Islands architecture — sparse client execution.
Keep the rendering interview playbook for whiteboard practice. Ask your teaching agent to run a timed mock interview and challenge your assumptions.
Practice
Short recall now helps decide what returns in your review queue.
Quick recall
Recall: The case: a global commerce product
Say your answer first, then reveal the explanation.
Design product pages and checkout entry for a catalog with millions of URLs. Product copy changes weekly; price and inventory change by market within seconds; recommendations may be slow; the cart is private; image galleries and add-to-cart are interactive. Search visibility, mobile performance, resilience, and operational cost matter.
Quick recall
Recall: Compose from constraints
Say your answer first, then reveal the explanation.
Select product requirements. The generated proposal is a starting hypothesis; your job is to explain every boundary and risk.
Quick recall
Recall: One defensible architecture
Say your answer first, then reveal the explanation.
It simplifies freshness but couples stable content to origin capacity and loses public cache reuse. Reserve request work for volatile or private regions.