Sarah Chen

When downstream systems degrade, jobs pile up and amplify outages. Add a simple “queue depth guard” so non-critical jobs skip or reschedule instead of making the backlog worse.

APIs are easier to operate when errors are structured and consistent. Wrap errors into a problem-details style response with a stable type and request_id so support can quickly trace issues.

Updating last_seen_at on every request creates hot rows and write amplification. Instead, track last seen in Redis and periodically flush to DB, or only write when the value meaningfully changes.

Auditing isn’t just “save everything”. Capture who did it, what changed, and why. Rails gives you dirty tracking; store diffs in a JSON column. Keep it minimal to avoid ballooning storage.

A robust feature flag read path should be fast, but also resilient to cache outages. Cache the computed result briefly and fall back to DB if needed; keep the interface dead simple.

If you have to hit multiple APIs, you can cut tail latency by running calls concurrently. Keep it bounded and use timeouts. Rails itself is thread-safe for reads; be careful with DB connections and use with_connection for threaded work.

Heavy work inside a transaction increases lock time and deadlock risk. Use after_save_commit to schedule slow tasks (thumb generation, external sync) once the write is durable.

A tiny custom validator keeps complex presence rules out of controllers. This example enforces that at least one of two fields is present (e.g., text content or an attachment).

When rendering JSON, the serializer layer can silently trigger extra queries. Force “preload then serialize” so your JSON rendering path is deterministic. This pattern scales well in Rails APIs.

If multiple admins edit the same record, use lock_version. Rails will raise on conflicting updates, and you can show a friendly “this changed underneath you” message. It prevents subtle lost updates.

If you have a queue table, avoid races by selecting and updating in one statement. Postgres UPDATE … RETURNING is the simplest building block for a correct custom queue / maintenance pipeline.

Sometimes raw SQL is the cleanest approach—just keep it safe. Use exec_query with bind params instead of interpolating values. You get both safety and correctness with types.