Cloud, deploys and infrastructure cheat sheet

Expand and contract changes

Split the change so every step works with both versions. Expand: add the new column (or field) alongside the old. Migrate: deploy code that writes both and reads the new with a fallback, then backfill old rows in batches. Switch: deploy code that reads and writes only the new. Contract: once no running code uses the old column, drop it. Each step is separately deployable and reversible, which is what rolling deploys need.

CREATE TEMP TABLE users (id int, fullname text);
INSERT INTO users VALUES (1, 'Ana Rao');
ALTER TABLE users ADD COLUMN display_name text;
UPDATE users SET display_name = fullname
WHERE display_name IS NULL;
ALTER TABLE users DROP COLUMN fullname;
SELECT display_name FROM users;

Graceful shutdown

Stop accepting new work but finish what's in flight. Mark itself not ready so the load balancer stops sending traffic, keep serving requests already received, let workers finish or return their current message to the queue, close database pools and flush logs and metrics, then exit before the platform's grace period (30 seconds by default in Kubernetes) ends and it's killed.

Containers and images

Small, reproducible and safe. Start from a slim, pinned base image, install locked dependencies in an early layer so code changes don't rebuild them, copy the app last, and use a multi-stage build so compilers stay out of the final image. Run as a non-root user, configure with environment variables, write logs to stdout, and keep one process per container. Scan images and rebuild regularly for security patches.

Kubernetes basics for backend developers

A Deployment keeps N replicas of your pod running and rolls out new versions gradually. A Service gives those pods one stable address and load-balances across ready ones; an Ingress or gateway exposes HTTP routes outside. ConfigMaps and Secrets inject configuration. Probes tell Kubernetes when to restart a pod or send it traffic. Resource requests decide scheduling, and limits cap usage: hitting the memory limit kills the pod, hitting the CPU limit throttles it.

Blue-green and canary releases

Blue-green runs the new version beside the old and switches all traffic at once, with instant rollback by switching back; it doubles capacity during the switch. A canary sends a small share of traffic (1%, then 10%, 50%) to the new version and compares its error rate and latency with the old before continuing, so a bad release hurts few users. Both need backward-compatible database changes, because old and new code share the data.

Feature flags on the server

A flag lets you deploy code dark and turn features on per user, percentage or tenant without a deploy. Evaluate flags server-side from a fast local cache, use a stable hash of user and flag for percentage rollouts so each user's experience doesn't flicker, and give every flag an owner and an expiry. Delete the flag and the dead branch once it's fully rolled out; old flags become hidden complexity.

import hashlib


def in_rollout(user_id: str, flag: str, percent: int) -> bool:
    h = hashlib.sha256(f"{flag}:{user_id}".encode()).digest()
    bucket = int.from_bytes(h[:4], "big") % 100
    return bucket < percent


users = [f"u{i}" for i in range(10_000)]
on_10 = {u for u in users if in_rollout(u, "new-checkout", 10)}
on_25 = {u for u in users if in_rollout(u, "new-checkout", 25)}
print(on_10 <= on_25, 900 < len(on_10) < 1100)

Configuration across environments

Build one artifact and configure it per environment at runtime, following the twelve-factor idea of config in the environment: URLs, feature settings and credentials come from environment variables or mounted files, never from code branches like if env == 'prod'. Validate all configuration at startup and fail fast with a clear error, so a missing variable doesn't surface as a strange bug hours later.

Infrastructure as code

Declaring servers, databases, networks and permissions in code (Terraform, OpenTofu, Pulumi, CloudFormation) makes infrastructure reviewable, repeatable across environments and recoverable after a disaster. Change it like application code: pull request, automatic plan showing exactly what will change, review, then apply from CI with a locked remote state. Watch the plan for destroys and replacements of stateful resources.

Backups, RPO, RTO and multi-region

Start from two targets: RPO, how much recent data you can afford to lose, and RTO, how long you can be down. Hourly backups alone mean an RPO of up to an hour; continuous WAL archiving or a streaming replica brings it to seconds. Test restores regularly, because an untested backup is a hope. Multi-region active-passive gives fast failover; active-active adds conflict handling and is much harder.

backup_every_min = 60
replication_lag_s = 5
print("RPO with hourly backups only:", backup_every_min, "min")
print("RPO with a streaming replica:", replication_lag_s, "s")

When serverless fits

Functions (AWS Lambda, Cloud Run functions) fit spiky or low-volume work, event handlers (a file uploaded, a message arrived) and glue code: you pay per use and scaling is automatic. They fit less well for steady high traffic (often cheaper on containers), latency-critical paths that can't absorb cold starts, long-running jobs beyond the time limit, and anything holding many database connections, since each instance opens its own.