Core Code
Core Code Modern Dev Handbook
RUST Contents
Rust Foundations for Production
Toolchain and Cargo Basics Project Layout Conventions Dependency Management Basics Configuration and Environment Basics Logging First Steps
Ownership, Borrowing, Lifetimes
Ownership Model Explained Borrowing Rules Lifetimes in Practice Smart Pointers: Box, Rc, Arc Interior Mutability
Types, Traits, and APIs
Traits and Generics Newtype Pattern API Design with Result and Option Serde Derive Basics Module Visibility Patterns
Error Handling & Reliability
Error Types with anyhow and thiserror Error Context and Chaining Retries and Timeouts Basics Idempotency Basics Input Validation Basics
Testing & Quality Gates
Unit and Integration Tests Mocking Strategies Coverage and Quality Gates CI Basics Contract Tests Basics
Concurrency & Shared State
Threads and Channels Mutex and RwLock Arc and Shared Ownership Deadlocks and Debugging Send and Sync Traits
Async Rust in Production
Async Runtime with Tokio Async Cancellation Async Timeouts Async Backpressure Basics Async Common Pitfalls
Web Services Basics
HTTP Server with Axum Routing and Middleware Basics JSON Errors and Problem Details Request IDs and Correlation Graceful Shutdown
Database & Migrations Basics
Choosing SQLx or Diesel Connection Pooling Migrations Basics Transactions Basics Query Timeouts
Observability Basics
Tracing Basics Metrics Basics Health Checks and Readiness Structured Logging Production Debugging Basics
Build, Release, Deployment Intro
Cross Compilation Basics Dockerizing Rust Services Configuration and Secrets Basics Release Profiles Rollback Strategies Basics
Security & Hardening Basics
Input Sanitization Deserialization Hardening SSRF and Egress Basics TLS Basics Dependency Vulnerability Scanning

Rollback Strategies Basics

Design releases so rollback is fast, safe, and predictable. Immutable artifacts, backward-compatible migrations, and deployment discipline reduce blast radius when a new version fails in production.
On this page

Rollback is not a panic button, it is a design decision

In production, failures are inevitable. The difference between a short incident and a prolonged outage is often the ability to revert safely. Rollback must be part of the release strategy from the beginning. If your deploy process does not support fast rollback, every release becomes high risk.

Production goals at this level

  • Immutable artifacts: each release is a versioned artifact that never changes after build.
  • Fast switch: switching to the previous version takes seconds, not minutes.
  • Backward compatibility: database schema and APIs allow temporary coexistence of versions.
  • No rebuild during incident: rollback uses an already built and tested artifact.

Immutable artifact principle

Every deployment should reference a specific build artifact, typically identified by a commit hash or version tag. That artifact must not change after it is built.

  • Build once in CI.
  • Tag image with commit SHA.
  • Promote the same image to staging and production.
# Example tagging strategy
docker build -t rust-service:abc123 .
docker push rust-service:abc123

Rollback means deploying a previous tag, not rebuilding from an older branch.

Deployment strategies that support rollback

Rolling update

Instances are gradually replaced. If error rate increases, stop rollout and revert to the previous version. This requires readiness probes and health checks to be correct.

Blue green deployment

Two environments exist: current and new. Traffic switches only when the new version is healthy. Rollback is a traffic switch back to the previous environment.

Canary deployment

A small percentage of traffic goes to the new version. If metrics degrade, revert quickly. Canary reduces blast radius but requires good observability.

Database migrations and rollback risk

Application rollback is easy if the database schema is compatible. The real risk often lies in schema changes.

Backward-compatible migration pattern

  1. Add new columns or tables without removing old ones.
  2. Deploy application version that can handle both schemas.
  3. Switch traffic gradually.
  4. Remove old columns only in a later release.

This pattern ensures that rolling back the application does not break due to missing columns.

What not to do

  • Dropping columns in the same release as code changes.
  • Renaming columns without compatibility layer.
  • Running destructive migrations without backups.

Runtime rollback checklist

  • Identify failing version tag.
  • Switch deployment to previous stable tag.
  • Verify readiness and health endpoints.
  • Monitor error rate and latency metrics.
  • Document incident while context is fresh.

Configuration rollbacks

Sometimes the issue is configuration, not code. Treat configuration as versioned and reviewable.

  • Store environment configuration in version control where possible.
  • Avoid manual changes directly in production without tracking.

Observability during rollback

Rollback should be observable. You should see:

  • Error rate decreasing.
  • Latency returning to baseline.
  • Readiness stable.

If metrics do not improve after rollback, the root cause may not be the application version.

Minimal example deployment revert

# Example Kubernetes style revert conceptually
kubectl rollout undo deployment rust-service

Human factors

Rollback decisions should be fast and ego-free. If a release causes measurable degradation, revert first, investigate second. Fast rollback protects users and buys time for careful debugging.

Common mistakes

  • Deleting old container images too early.
  • Not testing rollback in staging.
  • Combining large schema changes with major logic changes.
  • Changing infrastructure and application in the same deploy.

Operational checklist

  • Previous release artifacts are retained.
  • Rollback procedure is documented and tested.
  • Database migrations are backward compatible.
  • Metrics and health endpoints confirm recovery after revert.

Production maturity mindset

A mature production system assumes failure and optimizes for recovery speed. Rollback is not a sign of weakness. It is a core reliability feature. The faster and safer the rollback, the more confidently you can ship improvements.

Section summary

In this section, you learned how to build reproducible artifacts, package them into secure containers, manage configuration safely, tune release profiles, and design rollback-ready deployments. Together, these practices move a Rust service from development to production discipline.