Zero-Downtime Reloads And Graceful Restarts

Deployments often need runtime reloads. A graceful restart lets existing work finish while new workers use updated configuration or code. The exact command depends on the platform and process manager, but the behaviour should be understood before a production release.

Distinguish Reload From Restart

  • Distinguish reload from abrupt restart.
  • Drain or complete active work where supported.
  • Coordinate web workers and queue workers during deploy.

Exercise The Deploy Path

  • Deploy to staging.
  • Trigger graceful lifecycle action.
  • Send traffic during reload and inspect errors.

Include Workers And Rollback

  • Abrupt restarts interrupt requests and jobs.
  • Old workers may keep old code longer than expected.
  • Rollback needs the same lifecycle plan.

Deploy Sequence

1. Publish new release directory.
2. Switch current symlink or release target.
3. Reload web workers gracefully.
4. Restart queue workers gracefully.
5. Run health and smoke checks.
6. Roll back target if verification fails.

A web reload is only part of the release. Long-running workers may keep old application code until they restart, and rollback needs the same lifecycle steps as deployment. Exercise both directions while sending representative traffic and processing a queued job.

Release Compatibility

Zero-downtime delivery requires old and new versions to overlap safely. Database schemas, cache keys, session formats, queue payloads, and static assets must remain compatible during that window.

Use expand-and-contract database changes: add compatible structure, deploy code that supports both forms, migrate data, switch readers and writers, then remove old structure in a later release.

Drain Work Safely

Readiness should remove an instance from new traffic before shutdown. Allow bounded in-flight requests to finish, terminate or requeue work after the grace period, and restart workers so they load the new release.

Rollback Is A Designed Path

Rollback may mean routing traffic back, restoring the previous release pointer, or rolling forward with a corrective release. A destructive migration, irreversible external side effect, or incompatible message can make code-only rollback unsafe.

Practice

Practice: Plan A Graceful Deploy

Write the deploy sequence for an application with PHP-FPM web traffic and long-running queue workers. Include the rollback sequence.

Requirements

  • Distinguish reload from abrupt restart.
  • Drain or complete active work where supported.
  • Coordinate web workers and queue workers during deploy.
  • Deploy to staging.
  • Trigger graceful lifecycle action.
  • Send traffic during reload and inspect errors.
Show solution

Publish the new release, switch the active release target, reload FPM gracefully, and restart queue workers through their supervisor so new jobs use the new code. Send staging traffic and process a queued job during the change, then inspect errors and health checks.

Keep the prior release available. Rollback should switch the target back and repeat the same controlled lifecycle steps. A web-only check is incomplete when workers remain on old code.

Practice: Plan Expand And Contract

Rename a required database column without breaking old and new application versions.

Your answer must identify the intended behavior, the important failure case, and the evidence that proves the result.

Show solution

Add the new column first, deploy dual-read or dual-write compatibility, backfill and verify, switch fully to the new column, then remove the old column only after no old process remains.

Verify the real response, deployment, or workload rather than relying only on configuration text.

Practice: Drain Web And Worker Processes

Design shutdown behavior for PHP-FPM requests and queue workers.

Your answer must identify the intended behavior, the important failure case, and the evidence that proves the result.

Show solution

Fail readiness before termination, stop assigning new work, allow bounded in-flight operations to complete, requeue unacknowledged jobs, terminate after the grace period, and verify the replacement version is healthy.

Verify the real response, deployment, or workload rather than relying only on configuration text.