Rolling Update Deployment with Zero Downtime
When updating a web application in production, users often lose access or get 503 errors. Imagine: you roll out a new version, and half the requests fail with a timeout—the database couldn't switch over in time. The standard "stop → replace → start" approach doesn't work for services with SLA requirements of 99.9%. We configure Rolling Update—a strategy that eliminates downtime with minimal resource overhead. Our experience: 10+ years in DevOps, rolling update implementations for fintech and e-commerce platforms with millions of users.
Why Rolling Update Is the Best Choice for Zero-Downtime Deployment
Rolling Update replaces instances gradually: first 1–2 pods are updated, their health is verified, then the next. Unlike Blue-Green, it doesn't require double resources, and unlike Recreate, it doesn't stop all pods at once. This provides a balance between cost and fault tolerance. Rolling Update is 2× faster than Blue-Green in deployment time, and with proper configuration, downtime is completely eliminated.
| Parameter | Rolling Update | Blue-Green | Recreate |
|---|---|---|---|
| Additional resources | 0 | 2× | 0 |
| Downtime | No | No | Yes |
| Deployment time | Medium | Fast | Fast |
| Configuration complexity | Medium | High | Low |
| Risk of incompatibility | Higher | Lower | Lower |
Rolling Update offers the best price-to-reliability ratio for most production systems. This is confirmed by Rolling release on Wikipedia, where rolling update is recommended as the default strategy.
How to Configure Rolling Update in Kubernetes
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
minReadySeconds: 30
selector:
matchLabels: { app: myapp }
template:
metadata:
labels: { app: myapp }
spec:
containers:
- name: myapp
image: registry.example.com/myapp:v1.1.0
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
terminationGracePeriodSeconds: 60
kubectl set image deployment/myapp myapp=registry.example.com/myapp:v1.2.0
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=3
What Is Graceful Shutdown and Why Is It Needed?
Proper process termination is critical for zero-downtime. On receiving SIGTERM, the application must finish active requests, close connections, and release resources. If the app doesn't finish within the termination period, Kubernetes forcibly kills it, leading to request loss.
// Node.js/Express — graceful shutdown on SIGTERM
process.on('SIGTERM', async () => {
console.log('SIGTERM received, shutting down gracefully');
server.close(() => {
console.log('HTTP server closed');
});
await new Promise(resolve => setTimeout(resolve, 30_000));
await db.destroy();
process.exit(0);
});
How to Verify Application Readiness?
The readiness probe should check dependent services: database, cache, queue. Example in Laravel:
// Laravel — health check routes
Route::get('/health/live', function () {
return response()->json(['status' => 'ok']);
});
Route::get('/health/ready', function () {
try {
DB::connection()->getPdo();
Cache::store()->get('health-check');
} catch (\Exception $e) {
return response()->json(['status' => 'not ready', 'error' => $e->getMessage()], 503);
}
return response()->json(['status' => 'ready']);
});
How to Ensure Database Compatibility During Rolling Update?
When two versions coexist, the database schema must be compatible with both. The hard rule: migrations are run before deploying new code and must be backward-compatible. Avoid renaming or deleting columns immediately, or changing data types without intermediate steps.
We recommend a three-phase deployment: first add the new column (nullable) or new table. Then populate the new fields, switch the code to use them. Only in the third iteration remove old columns or tables. This approach eliminates compatibility errors when two versions run simultaneously.
Typical Problems When Configuring Rolling Update
One common mistake is setting maxSurge or maxUnavailable too small, which prolongs the deployment. For example, if maxSurge=1 and replicas=10, the update takes 10 rounds. Choose these parameters based on the total number of replicas and acceptable deployment speed. Another issue is incorrect readiness probes: they must check actual application readiness, not just return 200. If the probe does not include a database check, a new pod may start accepting traffic before the database is initialized, causing 500 errors. Also, often forgotten is terminationGracePeriodSeconds: if the app cannot shut down before SIGKILL, active requests are lost. Set it to at least 30 seconds.
What’s Included in the Rolling Update Setup?
- Analysis of current infrastructure and application architecture
- Configuration of Kubernetes Deployment or Docker Swarm service
- Writing proper readiness and liveness probes
- Implementing graceful shutdown (SIGTERM, request draining)
- Developing a backward-compatible migration strategy
- Testing on a staging environment with load
- Documentation of settings and procedures
- Team training on working with Rolling Update
Process
- Analysis: review current stack, infrastructure, deployment processes
- Design: select Rolling Update parameters, health checks
- Implementation: configure orchestrator, write probes, graceful shutdown
- Testing: validate on staging with load testing
- Deployment: roll to production, monitor first 24 hours
Timeline
| Stage | Duration |
|---|---|
| Basic Rolling Update setup (Kubernetes + health checks) | 2–3 days |
| Docker Swarm rolling update | 1–2 days |
| Backward-compatible migration development | 1–2 days |
| Full cycle with training | 3–5 days |
On a recent e-commerce project with 500k daily users, we reduced deployment downtime from 5 minutes to zero by implementing rolling update with proper health checks and graceful shutdown. The database schema changes were handled via three-phase migrations, ensuring zero errors during the transition.
Contact us for a consultation — we'll evaluate your project within 2 days. Order Rolling Update setup from professionals. Get a ready solution with guaranteed zero downtime and full compatibility.