Q259: Service Workers Cache Storage and Offline Security

What Interviewers Want To Evaluate

Interviewers want to know whether you can explain service workers as powerful network intermediaries, not only as a PWA checkbox.

They want to hear about scope, lifecycle, update problems, cache strategies, offline UX, sensitive data, and debugging.

Short Interview Answer

A service worker is a browser-managed worker that can intercept network requests within its scope, serve cached responses, enable offline experiences, and run background behaviors. Because it can control requests, it needs careful scope, HTTPS, update strategy, cache versioning, and sensitive-data rules. I would cache static assets and public content intentionally, avoid casually caching private responses, clear old caches during activation, and provide visible offline and update states so users do not get stuck on stale code.

Detailed Interview Answer

Service workers sit between the page and the network.

They can decide whether a request goes to:

network
cache
generated response
fallback response

That makes them powerful.

It also makes them risky when poorly managed.

Lifecycle

The service worker lifecycle includes:

registration
install
waiting
activate
fetch handling
update checks
unregistration

An updated service worker does not always control the current page immediately.

That can surprise teams after deployments.

Users may keep an old worker until pages close or the app prompts for refresh.

Scope

Scope defines which pages a service worker can control.

Keep scope as narrow as practical.

Example:

/app/

is narrower than:

/

A broad scope means the worker can affect more requests and more routes.

Cache Storage

Cache Storage stores request/response pairs.

It is separate from localStorage and IndexedDB.

Common cache categories:

static shell
versioned assets
public content
images
API data
offline fallbacks

Each category needs a policy.

Do not put everything in one unbounded cache.

Cache Strategies

Common strategies:

cache first
network first
stale while revalidate
network only
cache only

Use cache first for immutable assets.

Use network first for data that should be fresh but can tolerate offline fallback.

Use stale while revalidate for public content where instant display is useful and background refresh is acceptable.

Avoid caching sensitive user data unless the product explicitly needs it and the risk is understood.

Offline UX

Offline support is not only serving an old page.

Good offline UX explains:

what is available
what is stale
what failed
what will retry
what requires reconnection

For a learning platform, public chapters may work offline.

Progress sync may wait until the network returns.

Sensitive account actions should not pretend to complete offline unless the system has a reliable queue and conflict strategy.

Security Considerations

Service workers require HTTPS because they are powerful.

Security risks include:

caching private data
serving stale vulnerable JavaScript
failing to update after incident
overbroad scope
cache poisoning assumptions
leaking data between users on shared devices

Logout should consider cached private responses.

Deployment rollback should consider worker versioning.

Update Strategy

A safe update strategy includes:

cache version names
cleanup during activate
clear fallback behavior
user refresh prompt if needed
monitoring for old worker versions
manual recovery path

For critical security releases, teams may need to force a refresh or unregister old workers.

That decision should be intentional because it can disrupt users.

Debugging

Use browser tools to inspect:

registered service workers
controlled clients
cache entries
network source
offline mode
update lifecycle
console logs
unregister behavior

If a production bug appears only for some users, ask whether they have an old worker or old cache.

Common Mistakes

Common mistakes include:

caching all GET requests
not clearing old caches
not versioning cache names
serving stale HTML forever
forgetting logout cache cleanup
making offline UI indistinguishable from online UI
not testing update lifecycle
using broad scope by default

Interview Example

If asked, "Why do some users still see the old app after deployment?"

Answer:

"I would check whether a service worker controls the page, whether it serves cached HTML or assets, whether the new worker is waiting, and whether old caches were cleaned during activation. I would also inspect cache headers and CDN behavior because stale content can come from multiple layers."

Senior-Level Framing

The senior framing:

"A service worker is an owned network layer. I treat it like production infrastructure: scoped, versioned, observable, recoverable, and careful with sensitive data."

Practice Prompt

Design an offline strategy for:

public chapters
progress tracking
practice console code
PDF exports
authenticated settings

For each, choose cache strategy, invalidation, and failure UI.

Final Mental Model

Service workers can make an app resilient.

They can also preserve old mistakes.

Use them when the product needs offline or network control, and operate them with the same care as any other production layer.