concurrency

parking_lot provides drop-in replacements for Mutex, RwLock, and Condvar that are faster and smaller than std::sync. They use more efficient parking/unparking and don't poison on panic. I use parking_lot::Mutex in hot paths where lock contention matte

Transactions ensure data consistency through ACID properties. Atomicity guarantees all-or-nothing execution. Consistency maintains database constraints. Isolation prevents concurrent transaction interference. Durability persists committed changes. I u

I often need a fast read path for small datasets (like a list of active plans or an allowlist) that updates periodically. Instead of locking on every read, I store a pointer to an immutable snapshot in atomic.Pointer. Reads are lock-free and safe; ref

For high-performance concurrent code, atomics provide lock-free synchronization. The std::sync::atomic module has AtomicBool, AtomicUsize, etc., with operations like load, store, fetch_add, and compare_exchange. These compile to CPU-level atomic instr

When a cache key expires, it’s easy for a burst of requests to stampede the database. I use singleflight.Group to ensure only one goroutine performs the expensive fill per key while others wait for the shared result. This doesn’t replace proper TTLs o

When multiple clients can update the same record, I prefer optimistic locking over heavy row locks. The idea is simple: every row has a version that increments on each update. The update statement includes WHERE id=$1 AND version=$2, so if someone els

CompletableFuture enables non-blocking asynchronous programming in Java. I use supplyAsync() to run tasks in thread pools and thenApply() to chain transformations. thenCompose() flattens nested futures, while thenCombine() merges independent futures.

Ruby 3+ introduces Ractors for true parallelism without GIL limitations. Ractors are isolated actors—no shared mutable state. I use Ractors for CPU-intensive parallel processing. Messages pass between Ractors via send and receive. Async gem provides s

A clean shutdown is part of reliability, not an afterthought. The pattern I like is: (1) start servers and workers, (2) listen for SIGINT/SIGTERM, (3) call Shutdown with a deadline, and (4) wait for background goroutines to finish. http.Server.Shutdow

When you need to call multiple downstream systems, errgroup is a great way to express “do these in parallel, cancel on first failure.” The key is using errgroup.WithContext, not a plain WaitGroup, so the group can propagate cancellation. Each goroutin

Counters are classic race-condition bait. If two requests read, increment, and write, you’ll lose updates under load. I prefer letting Postgres do the atomic work with an upsert: INSERT ... ON CONFLICT ... DO UPDATE to increment the existing value. Th

Some dependencies are expensive to initialize (TLS-heavy clients, large config loads, SDKs that fetch metadata). I use sync.Once to ensure initialization happens exactly once, even under concurrent access. The important detail is capturing the initial