Review SSR personalization cache isolation

Review exercise · TypeScript

Advanced45 min

Review brief

A server-rendered dashboard adds personalization and a cache intended to reduce template work. Requests for different viewers and locales execute concurrently in the same long-lived process, and dependency failures are transient.

Behavioral contract

Never cache complete personalized HTML across requests. Only a viewer-independent public shell may use a process cache; all viewer, recommendation, flag, and locale rendering is request-local.
No mutable module-level value may carry viewer identity. Concurrent requests must render only their own authenticated viewer.
The optional public-shell cache evicts least-recently-used entries above 500 and removes rejected render promises so a transient failure can retry.
After authentication resolves, feature flags and recommendations are independent and must start concurrently. Anonymous requests use an empty recommendation list.
The response locale is the request locale, and all dependencies may reject without contaminating later requests.

Review instructions

1Trace two different viewers on the same path concurrently, plus a transient rendering failure.
2Anchor each finding to the narrowest useful changed line and explain the privacy, correctness, or latency impact.
3Recommend a direction rather than writing replacement code.
4Prioritize no more than five findings.

Learning objectives

• Separate cross-request public caching from request-local personalization
• Identify mutable module state in concurrent rendering
• Review cache failure, capacity, and fetch scheduling

src/ssr-personalization-types.tsTypeScript

@@ -0,0 +1,29 @@

1+export interface RenderRequest {

2+ path: string;

3+ locale: string;

4+ sessionCookie?: string;

5+}

7+export interface Viewer {

8+ id: string;

9+ displayName: string;

10+}

11+

12+export interface Recommendation {

13+ id: string;

14+ title: string;

15+}

16+

17+export interface PersonalizationDependencies {

18+ authenticate(sessionCookie: string | undefined): Promise<Viewer | null>;

19+ flags(viewerId: string | null): Promise<Readonly<Record<string, boolean>>>;

20+ recommendations(viewerId: string): Promise<readonly Recommendation[]>;

21+ renderTemplate(input: {

22+ shell: string;

23+ locale: string;

24+ viewer: Viewer | null;

25+ flags: Readonly<Record<string, boolean>>;

26+ recommendations: readonly Recommendation[];

27+ }): Promise<string>;

28+ renderPublicShell(path: string): Promise<string>;

29+}

Reference solution

The findings below are ordered by priority.

Findings

1. Complete personalized HTML is cached by path across viewers and locales

Location: src/render-personalized-page.ts:16-29

cachedPage wraps authentication-derived flags, recommendations, viewer data, and the request locale, but its key is only the path. The first viewer of /dashboard can have their name and recommendations served to every later viewer and locale on that path.

Cache only the viewer-independent public shell. Perform all personalization in request-local rendering outside the process cache.

2. Concurrent requests share one mutable viewer slot

Location: src/render-personalized-page.ts:8-15 and src/render-personalized-page.ts:23-28

Each request writes currentViewer, then reads it later after several awaits. Another request can replace the value between those operations, causing one response to render another authenticated identity even on distinct cache keys.

Remove module-level request state and close over the local viewer value throughout one render.

3. A rejected cache promise permanently poisons the path

Location: src/public-shell-cache.ts:1-12

The map retains the promise whether it fulfills or rejects. A transient template or dependency failure becomes the cached result, so all future requests to that path immediately fail without retrying.

Remove a rejected entry when it is still the promise stored for that key; a public-shell-only cache can retain successful values.

4. The process cache grows without the required bound

Location: src/public-shell-cache.ts:1-12

Every new path remains in pages forever. Dynamic or attacker-controlled paths can grow process memory without limit, and reads do not update any recency information.

Use an LRU policy capped at 500 entries for eligible public shells.

5. Independent personalization calls run serially

Location: src/render-personalized-page.ts:17-21

After authentication, the code waits for the shell, then flags, then recommendations. Flags and recommendations are independent once the viewer is known, so their latencies accumulate; the public shell can also start without waiting on either.

Start independent work together and await it as a group, while retaining the dependency on authentication for viewer-specific calls.

Reasonable non-findings

Authentication must resolve before viewer-specific flags and recommendations can be addressed.
Returning an empty recommendation list for an anonymous viewer is correct.
Deduplicating a public-shell render promise can be useful once its contents, failure behavior, and capacity are safe.
Propagating a dependency error for the current response is acceptable; only later requests must remain uncontaminated.