async-systemslisted

# Async Systems ## Iron Law `EVERY ASYNC BOUNDARY NAMES OWNERSHIP, LIFETIME, BACKPRESSURE, AND FAILURE SEMANTICS.` Async work fails when ownership, cancellation, retry, ordering, and failure handling are left implicit. ## When to Use - Designing or reviewing async execution, coordination primitives, background work, live updates, streams, brokers, ordering, and backpressure. - Investigating races, deadlocks, stuck tasks, event-loop blocking, starvation, memory growth, retry exhaustion, dead jobs, lag, poison messages, replay, ordering, or delivery issues. ## When NOT to Use - Ordinary request/response API design only; use `api`. - Remote-call timeout/circuit-breaker policy outside async mechanics; use `error-handling`. - Metrics, dashboards, alerts, and runbooks only; use `observability`. - Performance measurement without async design changes; use `performance`. - Database transaction isolation; use `database`. ## Core Ideas 1. For user-facing live updates, start with polling, SSE, or WebSockets. Escalate to Kafka/Kinesis/Redis Streams only after naming the requirement the simpler transport cannot satisfy: independent replay, long retention, audit history, offline catch-up, multi-service fanout, consumer-group scaling, partitioned throughput, or durable recovery. 2. Send immutable data across async boundaries. Keep mutable state owned by one scope. 3. Every spawned task belongs to a scope that cancels, awaits, or supervises it. 4. Eve