Zero-Downtime Deployment: Strategies for Backend Services and Databases

A deploy that drops requests for a few seconds is easy to ignore on a side project and expensive on a payments API, where those seconds become failed checkouts, retried webhooks and support tickets. Zero-downtime deployment is a set of practices that together keep every request served while a new version replaces the old one, and most of the failures come from the parts outside the deploy strategy itself: health checks that pass too early, processes that exit with requests in flight, and migrations that break the version still running.

Deployment strategies

Rolling deployment replaces instances in batches: the orchestrator starts new instances, waits for them to become healthy, shifts traffic to them, and stops old ones, repeating until the release is done. It needs little extra capacity and is the default on ECS, Kubernetes and Cloud Run. During the rollout, old and new versions serve traffic at the same time, which is the property every other practice in this guide has to account for.

Blue-green deployment runs the new version as a full second environment and moves all traffic at once, usually at the load balancer. Rollback means switching back, at the cost of double capacity during the release. The database is still shared, so migrations need the same care as with rolling releases.

Canary deployment sends a small share of traffic, such as 5 percent, to the new version and widens it as error rates and latency stay healthy. It catches regressions that only show under production traffic, at the cost of traffic-splitting infrastructure and metrics good enough to decide on.

Health checks that mean something

An instance should only receive traffic once it can serve it. A readiness check that returns 200 as soon as the HTTP server binds will route requests to an instance that has not connected to its database yet. A useful readiness check confirms the process has finished startup work, such as connecting pools and loading config, without calling every downstream dependency on each probe, which would turn a slow dependency into a fleet-wide outage.

Liveness checks are separate and should only fail when the process is stuck, since a failing liveness check restarts the instance.

Graceful shutdown and connection draining

When an old instance is stopped, the platform sends SIGTERM, removes it from the load balancer and, after a timeout, sends SIGKILL. The process has to stop accepting new connections, finish in-flight requests, and close pools within that window. In Go, that is signal.NotifyContext for SIGTERM followed by http.Server.Shutdown(ctx) with a deadline shorter than the platform timeout. Long-lived connections such as WebSockets and server-sent events need clients that reconnect, since a deploy will close them.

A background worker processing a queue message when it is stopped should either finish within the window or let the message return to the queue, which only works if handlers are idempotent and can safely run twice.

Database migrations without downtime

During any rolling or canary release, the old code keeps running against the new schema. A migration that renames a column, drops one, or adds a NOT NULL column without a default breaks the old version the moment it runs.

The expand and contract pattern splits breaking changes into compatible steps:

1. Expand: add the new column, nullable or with a default, and deploy code that writes to both old and new.
2. Backfill: copy existing data into the new column in batches.
3. Switch: deploy code that reads only from the new column.
4. Contract: in a later release, drop the old column or add the constraint.

On large Postgres tables, locks matter as well: CREATE INDEX CONCURRENTLY avoids blocking writes during index builds, and a lock_timeout on migration sessions stops a migration from queueing behind a long transaction and blocking everything behind it.

Zero-downtime deploys with Encore

Encore is infrastructure from code for TypeScript and Go, with a platform that provisions and deploys into your own AWS or GCP account. On AWS, services run on Fargate, and Encore orchestrates a rolling update that introduces new tasks gradually while removing old ones, as described in the AWS infrastructure docs. On GCP, Cloud Run services are configured for zero-downtime deployment with health check grace periods so containers have time to start before they receive traffic, per the GCP infrastructure docs.

Migrations run in sequence on each deploy, and Encore applies them before the application restarts with the new code, so the docs on changing the database schema ask that the old code keeps working with the new schema. Expand and contract fits that rule, and splitting a name column into display_name starts with an additive migration:

-- users/migrations/2_add_display_name.up.sql
ALTER TABLE users ADD COLUMN display_name TEXT;
UPDATE users SET display_name = name WHERE display_name IS NULL;

The service writes both columns until every running instance has the new code:

// users/users.go
package users

import (
	"context"

	"encore.dev/storage/sqldb"
)

var db = sqldb.NewDatabase("users", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

type RenameParams struct {
	DisplayName string
}

//encore:api public method=PUT path=/users/:id/name
func Rename(ctx context.Context, id int64, p *RenameParams) error {
	_, err := db.Exec(ctx, `
		UPDATE users SET name = $1, display_name = $1 WHERE id = $2
	`, p.DisplayName, id)
	return err
}

The migration in users/migrations/1_create_users.up.sql is the starting schema that the expand migration above builds on:

CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

A later release switches reads to display_name, and a third migration drops name once no deployed code reads it. For a large table, run the backfill in batches from a cron job or a one-off endpoint rather than in the migration itself.

encore run applies the migrations to a local Postgres, so you can run the old and new code against the expanded schema before you push. Deploys go out on each push through the GitHub integration, each with a build and test phase before the rollout begins.

A checklist for zero-downtime releases

• Readiness checks that pass only after startup work is done.
• Graceful shutdown that drains in-flight requests within the platform timeout.
• Idempotent queue handlers that tolerate redelivery.
• Clients that reconnect for WebSockets and streams.
• Migrations that the previous version of the code can run against.
• Destructive schema changes deferred to a later release.

Related guides

• EKS vs ECS vs Fargate
• Preview environments
• Deploy to AWS without Kubernetes
• What is Amazon ECS