async-systemslisted

# Async Systems ## Iron Law `EVERY ASYNC BOUNDARY NAMES OWNERSHIP, LIFETIME, BACKPRESSURE, AND FAILURE SEMANTICS.` ## When to Use - Designing or reviewing async execution, background work, live updates, streams, brokers, ordering, and backpressure. - Investigating races, deadlocks, stuck tasks, starvation, retry exhaustion, dead jobs, lag, poison messages, or delivery issues. ## When NOT to Use - Request/response API design; use `api`. - Remote-call timeout and retry policy; use `error-handling`. - Metrics, alerts, runbooks; use `observability`. - Transaction isolation; use `database`. ## Rules 1. For user-facing live updates, start with polling, SSE, or WebSockets. Escalate to Kafka, Kinesis, or Redis Streams only after naming the requirement the simpler transport cannot meet: independent replay, long retention, audit history, offline catch-up, multi-service fanout, consumer-group scaling, partitioned throughput, or durable recovery. Record that requirement with the choice. 2. Immutable data crosses async boundaries; mutable state has one owning scope. Job payloads carry stable identifiers and immutable inputs, never live session, request, or thread-local state. 3. Every spawned task belongs to a scope that cancels, awaits, or supervises it, with a deterministic shutdown path. 4. Every queue, channel, pool, stream, and buffer has a bound and an overflow policy. Blocking work cannot starve latency-sensitive work. 5. Locks are an escape h