Loading...
Loading...
Browse 8 real-world technical and behavioral interview questions about Rollback. Review scenarios, edge cases, and architectural best practices.
Stabilise first and diagnose second, which usually means reverting the change before you understand it. Take one artefact of evidence on the way out, time-box the decision aloud, communicate impact on a fixed cadence, and treat the incident as open until the damage the deploy caused is repaired.
Write the entry criteria before the parallel run begins so the decision is a checklist rather than a mood, ramp through a stepped population with an abort condition at each step, and recognise that rollback stops meaning redeploy once the new system takes its first authoritative write.
Build one immutable artefact, promote that same artefact through environments behind ordered quality gates, and deploy so traffic can be shifted back instantly. Rollback only stays possible if schema changes are backward-compatible expand-contract steps decoupled from the code deploy.
Rollback netcode predicts remote input so local gameplay never waits for the network. When the real input arrives, the client restores the saved state from that frame and re-simulates forward, trading CPU and correction artifacts for responsive controls.
The gateway owns state you cannot drain, namely resting orders at the venue and sequenced sessions, so a rolling deployment leaves a mixed fleet holding live obligations. Verification has to be a position reconciliation rather than a health check, rollback does not undo executions, and dead code must be deleted rather than disabled.
Re-pointing traffic at the previous version is only safe if nothing else moved with it. The feature transformations, the input schema and any consumer calibrated to the current score distribution may have changed, so the unit of rollback is the model plus its features and its contract.
Treat any payload the fleet loads as a release, because it changes behaviour in production exactly as a binary does. It needs schema and replay validation, a canary ring with its own health comparison, and a rollback that survives the change breaking whatever would apply the rollback.
The inner method joined the caller's transaction, so its rollback rule marked the one physical transaction rollback-only. Catching the exception hides it from your code but not from the transaction manager, which then refuses to commit. Use REQUIRES_NEW when the inner work must be able to fail alone.