Sarah Chen

If you store flags/settings in JSONB, query performance hinges on indexing. Partial indexes are a great compromise: index only the rows that matter for the hot path (e.g., enabled flags).

For Postgres search beyond trivial ILIKE, maintain a tsvector column and a GIN index. Update it via trigger or application logic. This keeps search fast and predictable even as your dataset grows.

Active Storage makes uploads easy; production makes them dangerous. Validate content type and size at the model layer, and keep the error messages user-friendly. This prevents large or unexpected uploads from blowing up costs and processing queues.

Normalize before validation to avoid “same email, different casing/whitespace” bugs. Keep normalization deterministic and small; put it in the model so imports, consoles, and controllers all behave the same.

Set a rough query budget per request in dev/test and alert when exceeded. This is a pragmatic way to keep performance regressions visible without requiring a full APM setup.

A simple fixed-window rate limiter is often enough for endpoints like login, password reset, webhooks, or expensive searches. Use atomic Redis INCR + EXPIRE with a stable key and return remaining quota for UX.

Rails enums are nice, but the DB should enforce allowed values. Use a CHECK constraint (or native enum type) plus the Rails enum mapping. It prevents bad writes from console scripts and future migrations.

If a hot key expires, you can stampede your DB. race_condition_ttl lets one process recompute while others serve stale content briefly. This is a reliability pattern masquerading as caching.

ETags are a simple high-impact performance lever: they reduce bandwidth and controller CPU. Use stale? with a stable ETag component list and last_modified so intermediary caches and browsers can do conditional GET.

Authorization filters often become string-SQL soup. Use Arel to build composable scopes that are still readable and safe. This snippet shows a “visible_to(member)” scope with a join and a condition that can evolve without turning into interpolated SQL

Enqueueing jobs inside a transaction can create “ghost jobs” when the transaction rolls back. Use after_commit or after_create_commit to enqueue work only after the DB commit succeeds.

Counter caches drift (deleted records, backfills, manual SQL). A repair job that recomputes counts safely is invaluable. It’s the kind of operational code you’re glad you wrote the first time a dashboard is wrong.