That interval is where a simple column rename can break otherwise correct code. The new version asks for the new name while the old version still asks for the old one.

Add before removing

Suppose customers.name needs to become customers.display_name. An illustrative transition is:

1. Add the new nullable column while keeping the old column usable.
2. Deploy code that writes both values in the same transaction and can read through the transition.
3. Backfill existing rows in bounded batches, with a retry-safe condition.
4. Check that all writers have migrated and the backfill is complete.
5. Switch reads to the new field; remove the old field in a later change.

The details depend on the database and workload. A batch backfill can race with live updates, and a forgotten background job may still write only the old column. The compatibility plan needs to include those writers, not just the web application.

Separate reversible steps

Before removing a column, rolling the application back may still be straightforward. After deletion, the previous code can no longer rely on the data it expects. Treat that deletion as a separate decision with its own verification and recovery plan.

The SQL statement’s apparent simplicity also says little about its operational cost. Check the database version’s behaviour for locks, table scans and constraint validation. Rehearse on a representative dataset when those costs could interrupt traffic.

A useful migration note explains what can run during each stage, how completion is checked, and what rollback means at that point. That note is often more valuable than a clever one-line migration.

Reference: PostgreSQL documentation on modifying tables.

Imagine an endpoint that returns a price. A key containing only the product ID looks reasonable until the price also depends on currency, customer tier or region. Those inputs are part of the result even if they do not appear in the URL.

1

cache_key = (product_id, currency, customer_tier, pricing_version)

This is an illustrative key, not a complete pricing design. Its purpose is to make the dependencies visible. If account-specific permissions affect the response, those boundaries also need to be reflected in the caching strategy.

Freshness is a product decision

A five-minute-old avatar and a five-minute-old available balance carry different consequences. A time-to-live is meaningful only after someone decides what stale data is acceptable for that operation.

Expiry also does not solve every invalidation problem. An update followed immediately by a read can still return an old cached value. Options include invalidating on writes, versioning keys or accepting a documented delay. Each choice creates different failure modes.

Check the uncomfortable cases

Before measuring a hit rate, I would check that:

• Two users cannot receive each other’s private result.
• A change in an input that affects the result changes the cache lookup.
• An update behaves as promised on the next read.
• A cache outage has an intentional failure or fallback path.

For HTTP caches, headers add another layer to this contract. no-cache permits storage but requires validation before reuse; no-store tells a cache not to store the response. They are not interchangeable ways to say “please be fresh.”

A cache is easier to operate when its correctness rule fits in a sentence. The performance measurements come after that rule is clear.

Reference: HTTP caching specification, RFC 9111.