concurrency

I avoid unbounded goroutines when processing queues; they look fine in staging and then blow up under a burst. This worker pool keeps a fixed number of workers and a bounded channel for jobs, which creates backpressure by design. The Submit call respe

When you need shared mutable state across threads, Arc<Mutex<T>> is the idiomatic pattern. Arc is an atomic reference counter that allows multiple ownership, and Mutex provides interior mutability with runtime locking. You clone the Arc fo

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.

Sometimes you just need ‘only one worker does this thing at a time’, and building distributed locks from scratch is risky. Postgres advisory locks are a pragmatic option when your DB is already the source of truth. I derive a deterministic lock key (l

Tokio's spawn creates a new async task that runs concurrently on the runtime's thread pool. Unlike OS threads, tasks are lightweight (kilobytes of memory) and scheduled cooperatively. Each task must be 'static and Send, meaning it can't borrow local v

In-flight request count is a simple but powerful saturation signal. I keep an atomic.Int64 gauge that increments at the start of a request and decrements in a defer, which makes it robust even on early returns. This gauge can be exported via expvar, P

Under real concurrency, even ‘simple’ write paths can hit serialization failures, especially with stricter isolation levels. Instead of pretending it won’t happen, I wrap the transaction in a small retry loop with jitter. I only retry on known transie

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.

select_for_update() locks rows until transaction completes, preventing race conditions. I use it for operations requiring read-modify-write atomicity like decrementing stock or updating counters. The lock is released on transaction commit/rollback. Fo

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.

When multiple users can update the same record simultaneously, optimistic locking prevents lost updates by detecting conflicts. Rails provides built-in support via a lock_version integer column that increments on every update. If two users load the sa

If you fan out work (HTTP calls, DB reads, image processing), the failure mode isn’t just “slow,” it’s “everything gets slow” because you saturate CPU or downstream connections. A semaphore is a simple way to cap concurrency. The important part is mak