redis

Sometimes exact counters aren’t worth the write cost. For high-traffic views, track increments in Redis and periodically aggregate into the DB. It’s an operational tradeoff that can dramatically reduce DB pressure.

Most ‘caching’ bugs are really invalidation bugs, so I stick to a simple cache-aside pattern with conservative TTLs and treat cache misses as normal. The big failure mode to avoid is a stampede: if many requests miss at once, you can crush your DB. Fo

Background jobs will fail in production, so I like having a predictable story for retries and poison messages. BullMQ is a solid middle ground: Redis-backed, straightforward, and good enough for most apps. I set explicit attempts and backoff, and when

Retries are great, but duplicates are inevitable—workers crash, Redis reconnects, deploys happen. I prefer building idempotency into the job key itself. BullMQ supports a jobId that acts like a de-dupe key: if a job with the same id already exists, en

Redis provides fast in-memory caching for Django. I configure it as cache backend and use for session storage. I cache expensive querysets, computed values, and API responses. The cache.get_or_set() method simplifies cache-aside pattern. For cache inv

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.

Sometimes you need “only one runner globally” (backfills, refresh jobs). A Redis mutex with TTL avoids deadlocks if the process dies. It’s not perfect, but it’s a solid pragmatic tool.

Presence is often more about “who is here now” than perfect accuracy. Use Redis sets with expiries updated by pings. This keeps the system simple and operationally understandable.

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.