Q093: Frontend Rollback and Recovery Playbooks
What Interviewers Want To Evaluate
This question tests whether you can recover from bad frontend releases quickly and safely. Interviewers want rollback strategy, feature flags, CDN behavior, cached assets, migrations, communication, verification, ownership, and post-recovery cleanup.
Senior frontend engineers should know that rollback is a product safety mechanism, not a sign of failure.
Short Interview Answer
A frontend rollback playbook defines how to identify a bad release, choose rollback or mitigation, execute safely, verify recovery, and communicate status. I would include release history, feature flag controls, deployment rollback steps, CDN and cache considerations, data migration constraints, monitoring dashboards, owner contacts, and validation checks for critical flows. The playbook should be practiced before incidents so recovery is not improvised under pressure.
Detailed Interview Answer
Frontend rollback can be tricky because users may have cached HTML, JavaScript chunks, service worker assets, open tabs, or feature flags that outlive a deployment.
Start with the incident question:
What changed?
What users are affected?
Is rollback safe?
Is there a flag kill switch?
Are assets cached?
Are data changes backward-compatible?
How will we verify recovery?
Who communicates status?
Rollback Options
Rollback options include reverting deployment, disabling a feature flag, changing remote configuration, rolling forward with a hotfix, purging CDN cache, disabling a third-party script, or temporarily hiding an entry point.
The right action depends on user impact and safety.
Feature Flags
Feature flags are the fastest mitigation when the broken behavior is isolated behind a flag. The playbook should document where flags live, who can change them, how long propagation takes, and how to verify the flag state.
A flag is not useful if the risky code was not actually gated.
CDN and Cached Assets
Frontend assets are often cached aggressively. Hashed assets are usually safe because new filenames represent new content. HTML, service worker files, and runtime configuration may need special care.
If a service worker cached bad assets, rollback may require a service worker update strategy.
Data Compatibility
Rollback is harder when a frontend release depends on new backend data shape or writes data in a new format. Backward-compatible API and data changes make rollback safer.
Senior engineers should coordinate rollback plans across frontend and backend.
Verification
After rollback, verify real user recovery. Check error rate, route load success, key workflows, browser segments, feature flag state, and support reports.
Do not declare recovery only because the deployment command completed.
Communication
During recovery, communication should include impact, mitigation status, owner, next update time, and verification status.
Keep user-impact language clear. Avoid internal implementation jargon when communicating outside engineering.
Common Mistakes
A common mistake is having rollback steps spread across chat history. Another is assuming deployment rollback handles service workers, cached HTML, or feature flags automatically.
Another mistake is rolling back without checking whether data or API compatibility makes rollback unsafe.
Senior Trade-Offs
Rollback restores known code but may remove desired features. Hotfixing keeps the release but may be riskier under pressure. Flag disablement is fast but only works for isolated behavior.
The senior answer should prioritize user recovery over pride in the release.
Code or Design Example
A rollback playbook can be modeled as a structured checklist.
type RollbackPlaybook = {
service: string;
criticalFlows: string[];
rollbackCommandOrLink: string;
featureFlags: string[];
cacheRisks: Array<"html" | "service-worker" | "cdn" | "runtime-config">;
verificationDashboard: string;
owner: string;
};
The exact format can be markdown, but the information should be findable.
Production Example
Suppose a release breaks login for Safari users. The team disables the new login experiment flag, verifies Safari login succeeds, monitors error-free sessions, and then opens a follow-up fix.
If the issue was in ungated shared auth code, deployment rollback may be required instead.
Practice
Teams should occasionally test rollback paths. A rollback process that has never been used may fail during a real incident because permissions, commands, or assumptions changed.
Practice can be lightweight, such as reviewing the playbook during release readiness.
Lead Engineer Perspective
A lead engineer should make recovery boring. That means clear playbooks, permissions, dashboards, feature flag ownership, cache awareness, and cross-team compatibility.
The best incident process is calm because the team already knows the next step.
Revision Notes
Rollback and recovery require mitigation choices, cache awareness, data compatibility, verification, communication, and practiced playbooks.
Key Takeaways
Rollback is a user-safety mechanism. It should be planned, documented, and verified.
Follow-Up Questions
- When would you rollback versus hotfix?
- How do feature flags help recovery?
- How can service workers complicate rollback?
- Why does API compatibility matter?
- What should a rollback playbook include?
- How do you verify recovery?
- How do CDN caches affect frontend releases?
- Who should communicate during rollback?
- How do you practice rollback?
- What makes rollback unsafe?
How I Would Answer This In A Real Interview
I would say rollback playbooks reduce recovery time. I would include impact assessment, mitigation choices, deployment rollback, flag controls, cache and service worker checks, API compatibility, verification dashboards, communication, and post-recovery cleanup.