Emails should be idempotent. Store a delivered marker (or unique key) so retries don’t spam users. This pattern is especially useful for receipts and password reset flows.

Tagging systems can be expensive. For quick “top tags” features, compute from the join table with group and count. Avoid loading full taggable records.

Avoid writing rows when nothing changed—especially in batch jobs. Check changed? or compute the would-be update and skip if identical. This reduces bloat and autovacuum pressure.

Deploys happen while jobs are in the queue. Be defensive: accept both old and new payload shapes, and keep migrations forward-compatible. This prevents “deploy broke jobs” incidents.

Deadlocks happen under load. When the operation is safe to retry, rescue the deadlock exception and retry with jitter. Keep retries bounded and log when it happens.

A real health check tests the dependencies you care about (DB, Redis). Keep it fast and don’t make it do expensive queries. Use it for load balancers and alerts.

For leaderboards, let the database do ranking. Window functions are fast and expressive. Use them to compute daily top N without Ruby loops.

Tags are user input, so normalize aggressively: downcase, strip, collapse whitespace, remove duplicates. Doing this at write time keeps search/filter logic clean and avoids messy edge cases.

If you sort by a non-unique column (score, created_at), pagination can “skip” or “duplicate” records. Always add a secondary unique key like id for deterministic ordering.

Direct deletes can be risky and slow. Mark records for deletion, then sweep in batches in a maintenance job. This gives you observability and a rollback window.

When you need to invalidate caches by changing timestamps, use touch_all to avoid per-record callbacks. It’s fast, explicit, and doesn’t run unintended side effects.

When adding a new query path, run EXPLAIN in CI or a smoke task to catch missing indexes before production. You don’t need full query plans everywhere—just guard the hot paths.