Articles
Service Worker Interview Questions: Lifecycle, Cache Updates, and Offline Failures
Practice service worker interview questions on waiting, activation, cache updates, offline failures, two-tab compatibility, and safe retry boundaries.
Service worker interview questions are usually easier to reason about when you track three separate identities: the page that is already running, the worker controlling its requests, and the cache entries available to that worker. Installing a new script does not automatically replace the JavaScript in every open tab. An update must preserve compatibility across those boundaries.
This guide explains lifecycle, cache updates, and offline failures through an original two-tab release scenario. Official facts come from web.dev and MDN. Our inference and recommendations concern how to explain release choices and test their consequences.
What does a service worker do, and what does it not own?
A service worker runs in a worker context and can handle events such as fetches for controlled clients. It does not directly access the page DOM. Registration and control have origin and scope boundaries, and deployment normally requires a secure context, with local-development exceptions documented by browsers.
MDN's Using Service Workers introduces those mechanics. The practical consequence is that a worker needs explicit communication when it must coordinate with a page. It cannot silently rewrite every open component's in-memory state.
Its execution is also not an always-running application server. The browser can stop an idle worker and start it again for an event. Do not store essential durable state only in global variables or rely on an indefinite timer to perform critical work later.
In an interview, ask which requirement needs a service worker: offline navigation, controlled asset caching, background event handling, or another supported feature. “Make everything faster” is too broad to define correct behavior. Some requests should deliberately continue to the network without a cached fallback.
Why is installed different from controlling the page?
The lifecycle includes installation and activation, with a waiting phase commonly separating a newly installed update from activation while the previous worker still controls clients. The web.dev lifecycle guide explains why this protects existing pages from an uncoordinated controller replacement.
A first page visit can register a worker without having that worker control the navigation that already loaded the page. A reload or later navigation may then be controlled, depending on activation and claiming behavior. Avoid saying that successful registration proves every request in the current tab passed through the new worker.
State the observation you would inspect: registration state, the waiting worker, and the page's controller. These are different objects and signals. A successful install log answers a narrower question than “is this tab using the new caching policy?”
Installation work that matters to readiness should be attached to the event through waitUntil. If required precaching fails, treating the new version as unavailable is often preferable to activating an incomplete offline experience. That is a release decision grounded in the application's minimum working set.
Walk a two-tab update without mixing versions
Imagine an original practice application with two tabs, both running page bundle A and controlled by worker A. Worker B downloads after a release. Its installation succeeds, but it waits while A still has controlled clients.
| Moment | Existing tabs | New worker | Design question |
|---|---|---|---|
| Before release | Page A, controller A | None | Which assets must remain available? |
| B installs | Page A, controller A | B waiting | Is B's minimum cache complete? |
| Update is offered | Unsaved work may exist | B waiting | Can users safely reload now? |
| B activates | Old page code may still exist | B active | Are old requests compatible? |
| Tabs reload | Page B under intended controller | B active | Can obsolete assets now be retired? |
The important distinction is activation versus page reload. A controller change does not itself replace the page's already evaluated code. If an old page requests a lazy-loaded chunk after activation, your release design must still give it a coherent answer.
A practical strategy is to keep immutable, content-versioned assets available long enough for old clients and present an update action when reloading is safe. Another strategy is immediate activation with an explicit backward-compatible worker contract. Neither is universally correct.
Explain the user consequence before naming the API. A document editor may prioritize unsaved work; a read-only kiosk may accept an immediate reload. The interview answer should make that requirement change the rollout policy.
What do skipWaiting and clients.claim actually change?
skipWaiting() asks a waiting worker to proceed toward activation. It does not refresh open pages or migrate their state. MDN's skipWaiting reference documents its lifecycle role.
clients.claim() allows an active worker to take control of eligible clients within scope, with controller-change notification. It does not mean every browser tab on every origin becomes controlled. See the separate Clients.claim documentation.
These APIs solve different transitions. Calling both by habit can create version skew: an old page begins talking to a new controller whose assumptions changed. If your answer proposes them, state why the page-worker protocol remains compatible.
An original interview follow-up is to change a message from { action: "save" } to { operation: "save", schema: 2 }. What happens to an already-open page that sends the old shape? The worker should have an explicit compatibility or rejection policy; a cache-name change does not solve the message contract.
Likewise, a reload prompt needs protection against repeated reload loops. Handle controller changes deliberately, preserve recoverable draft state, and test more than one tab rather than relying on a single happy-path demo.
How should cache policy depend on the request?
Cache Storage is an application-managed request-response store, not a substitute for thinking about freshness. MDN's Cache reference explains that entries do not automatically expire through an application-defined TTL and that the API does not enforce HTTP caching headers in the same way as the HTTP cache.
Choose policies by meaning, not one universal handler:
| Request class | Possible policy | Failure to explain |
|---|---|---|
| Versioned static bundle | Cache-first with immutable identity | Missing old chunk after release |
| Navigation document | Network-first with a deliberate offline fallback | Returning stale HTML with incompatible assets |
| Public reference data | Stale-while-revalidate where acceptable | User sees old data without a freshness signal |
| Account-specific response | Explicit authorization and storage policy | Cached data crosses sessions |
| Mutation | Network operation or durable outbox design | Retry duplicates a completed action |
These are recommendations, not mandated defaults. A price quote and an icon have different correctness requirements. Ask how stale data may be, who may read it, and what an offline user should be allowed to do.
Do not return a cached HTML offline page for every failed request. An image, JavaScript module, and JSON response require different representations. A broad catch handler can transform a network failure into a confusing parser error.
When caching a fetched response that you also return, account for the response body's consumption semantics, commonly by cloning it. Also decide whether an HTTP error response should enter the cache. A fulfilled fetch promise does not mean the response status was successful.
How do you update caches without deleting needed assets?
Use cache names that identify the application and its version or purpose. During cleanup, restrict deletion to caches the application owns. Cache Storage is shared within the relevant origin storage context; deleting every unfamiliar name can damage another feature using the same origin.
The harder question is when old data becomes safe to remove. If the new worker activates while old pages remain, those pages may still request old assets. An immediate blanket cleanup can break them even when the new version works perfectly in a fresh tab.
Our suggested release invariant is: every supported live page version can obtain the assets and protocol behavior it still needs. That can be satisfied through a retention window, compatible routing, coordinated reloads, or a more explicit client-version scheme. State the operational trade-off rather than promising that one cache-deletion loop is always safe.
A rollback also needs planning. Publishing an older worker script does not instantly revert every running client or undo a data migration. Keep compatible assets available and test the recovery path before relying on rollback during an incident.
What fails during offline cold start?
Offline support has several meanings. A previously visited route may work while an unvisited deep link fails. The shell may load but lack the data needed to render useful content. A tab kept open through a network outage is different from restarting the browser offline.
Build a test sequence with distinct states: first visit online, controlled revisit, offline reload, offline deep link, missing cache entry, and storage cleared or evicted. Do not describe a page as universally offline-ready because one warm tab continued to display its existing DOM.
Storage can be unavailable, constrained, or removed under the browser’s quota and eviction policies. Treat cached content as recoverable unless the product deliberately uses a stronger persistence design and clearly communicates its limits. A user-authored draft needs a different recovery contract from a replaceable stylesheet.
Provide an honest failure state when required content is absent. “Available offline” should mean the specific feature has the needed dependencies, not simply that a worker is registered. Explain which operations remain readable, which are queued, and which require connectivity.
Does background work guarantee eventual delivery?
A service worker is not a guarantee of continuous execution. Browser support, scheduling, network access, and user behavior affect background opportunities. A critical queued operation should remain discoverable when the application next opens rather than depending on one background event firing at the desired time.
If you propose offline writes, give each operation a stable identifier, persist its status, and distinguish “queued locally” from “accepted by the server.” Losing the response after a successful server write creates an unknown outcome. Retrying safely requires a server-side idempotency or reconciliation contract.
This is our design recommendation for the exercise, not a promise supplied by the service-worker API. The worker provides an execution context; your data model provides the operation's meaning and recovery behavior.
Also handle logout. A queue created under one account should not silently execute under another account's credentials. Define what is cancelled, retained for the original user, or explicitly confirmed after authentication returns.
What evidence should a debugging answer include?
Record the page version, worker state, controller identity, cache names, requested URL, and whether the response came from the worker's chosen path. A stale response can originate in several layers, including the network's HTTP caches; do not blame the service worker without tracing the request.
Test failed installation by making a required dependency unavailable. Test two tabs with different loading times. Test an old page requesting a lazy chunk after the new worker activates. Test logout followed by another account, and test a fresh offline navigation with no cached document.
Developer tooling can change lifecycle behavior through update-on-reload or bypass options. Record those settings and disable development shortcuts when validating the actual release policy. Otherwise the test may prove a workflow users never experience.
A good final explanation names the failed boundary and the repair's scope. For example, an old page could not load its chunk because activation cleanup deleted A's assets. Retaining supported assets fixes that scenario; it does not prove every offline feature or every browser version is correct.
Practice release and recovery decisions
The service-worker extensions are our practice suggestions, not the original questions' guaranteed implementation requirements.
| Question | Service-worker follow-up |
|---|---|
| Reduce frontend network requests efficiently | Choose freshness rules for each response class |
| Design an Offline Multi-Device E-Book Reader | Define a complete offline download manifest |
| Design a cloud file sync service | Separate local queue state from accepted remote state |
| Build a Reliable Streaming Chat UI | Handle reconnects and unknown write outcomes |
| Implement Role-Aware User Information Views | Prevent cache or queue leakage across sessions |
Choose one Frontend Engineer exercise and draw its page-controller-cache timeline. Then introduce a second tab and an offline restart. Explain which compatibility promise survives each transition and how you would verify it.
Sources and Further Reading
- web.dev: The service worker lifecycle
- MDN: Using Service Workers
- MDN: Cache API
- MDN: skipWaiting
- MDN: Storage quotas and eviction
- MDN: Clients.claim
Research checked September 14, 2026. Confirm browser support and lifecycle behavior in the environment used for your application.