Q285: Scalability Tradeoffs Client Server and Edge Responsibilities

What Interviewers Want To Evaluate

Interviewers want to know whether you can reason about scale across browser, server, CDN, and edge layers.

They are testing whether you know what belongs on the client, what belongs on the server, what can be cached at the edge, and what must stay authoritative.

Short Interview Answer

Scalable frontend architecture assigns responsibilities to the right layer. The client owns interaction, presentation, local UI state, and progressive enhancement. The server owns authorization, business rules, persistence, secrets, and authoritative data. The edge or CDN can cache public content, route requests, compress assets, and reduce latency. Good scalability comes from reducing unnecessary work, caching safely, streaming useful UI early, splitting bundles, and keeping trust boundaries clear.

Detailed Interview Answer

Frontend scalability is multi-layered.

It includes:

browser CPU
browser memory
network latency
bundle size
API load
server rendering cost
CDN cache behavior
database pressure
team ownership
deployment frequency

If you optimize only one layer, you may move the bottleneck somewhere else.

Client Responsibilities

The client is good at:

interactions
local UI state
form responsiveness
optimistic feedback
incremental rendering
offline hints
animation
accessibility behavior

The client is not good at keeping secrets or enforcing final authorization.

Use the browser for user experience.

Use the server for trust.

Server Responsibilities

The server owns:

authentication
authorization
business rules
runtime validation
database writes
secret usage
audit logging
long-running jobs
canonical data

Server work can scale through caching, queues, database indexes, and horizontal capacity.

But server rendering every page for every user may be unnecessary.

Edge and CDN Responsibilities

The edge is useful for:

static asset delivery
public page caching
image optimization
compression
redirects
geographic latency reduction
light routing decisions
security headers

Do not put complex business logic at the edge unless there is a clear reason.

Edge runtimes have constraints.

Caching Strategy

Cache based on data type:

public static content: cache aggressively
hashed assets: immutable
HTML: controlled freshness
personal data: private or no-store
API summaries: endpoint-specific policy
mutations: no cache, invalidate reads

Bad caching can leak data.

Good caching can make the app feel instant.

Rendering Strategy

Choose:

SSG for stable public content
SSR for per-request personalized data
streaming for independent slow sections
client islands for interaction
CSR for highly dynamic private tools
ISR when freshness can lag

Modern apps usually combine these.

Learning Studio uses static MDX well because handbook content is public and stable.

Future cloud progress might be personalized and should use a different strategy.

Bundle Scalability

Bundle size affects every user.

Use:

route splitting
dynamic imports
client islands
server components
tree-shaking
dependency review
asset optimization

Do not ship admin-only code to every public reader.

Do not put static content inside large Client Components.

Data Scalability

Large data sets need:

pagination
filtering
search indexes
virtualization
summary endpoints
lazy detail loading
request cancellation
cache keys

Fetching everything and filtering in the browser is only acceptable for small bounded data.

State the boundary.

Team Scalability

System design also includes team scale.

Use:

clear route ownership
shared components
design tokens
API contracts
feature flags
testing standards
observability
documentation
review checklists

Architecture should help teams move safely.

Interview Example

If asked, "Should search run on the client or server?"

Answer:

"It depends on data size, sensitivity, freshness, and ranking complexity. For a small public static handbook, client-side search may be fine. For private, large, frequently changing, permissioned data, server-side search with pagination and authorization is better. I would state the threshold and design migration if data grows."

Common Mistakes

Common mistakes include:

putting secrets on the client
server-rendering everything without need
caching private data publicly
filtering huge data sets in browser
shipping every feature in one bundle
ignoring edge runtime constraints
not planning invalidation
not considering team ownership

Senior-Level Framing

The senior framing:

"I scale frontend systems by putting work where it belongs: interaction in the client, authority on the server, safe caching at the edge, and clear ownership across teams."

Practice Prompt

Decide where each belongs:

public question content
cloud progress writes
search ranking
PDF generation
practice console execution
analytics event ingestion
auth token refresh
image optimization

Choose client, server, edge, or background job, and explain why.

Final Mental Model

Scalability is responsibility placement.

The right layer reduces cost, improves UX, and preserves trust boundaries.