# State, Side Effects, and Concurrency

## Classify state

| Role | Required questions |
| --- | --- |
| authoritative | durability, transactions, conflicts, recovery |
| derived | rebuildability, cost, allowed staleness |
| cache | source fallback, invalidation, stampede, degraded mode |
| message | delivery, acknowledgment, duplication, ordering, retention |
| coordination | atomicity, owner, lease, expiry |
| temporary | lifecycle, capacity, cleanup |
| aggregate | concurrent update, precision, window, late data |

A product can serve multiple roles. Derive rules from business semantics, not the product name.

## Define side-effect boundaries

List database writes, payments, quotas, messages, notifications, and third-party calls. Identify the business commit point, failures before and after it, safe retry conditions, idempotency key, uniqueness or conditional update, transaction or outbox, and compensation behavior. Define how to confirm an operation that succeeded but lost its response.

Do not treat catch-and-retry as a reliability design. Retry only transient failures within a remaining deadline and only when duplicated side effects are controlled.

## Consumers

Define at-most-once, at-least-once, or acceptable-loss semantics. Check:

- ACK or checkpoint timing relative to required side effects;
- duplicate safety when business work succeeds but ACK fails;
- crash recovery for unacknowledged work;
- maximum retry, backoff, jitter, non-retryable errors, and dead-letter or quarantine handling;
- replay and idempotency;
- global, partition, or business-key ordering;
- input rate, processing rate, backlog, oldest age, and drain time;
- downstream capacity before scaling consumers.

One poison item must not block a whole partition forever.

## Multi-instance behavior

- Process-local locks do not provide cross-instance exclusion.
- Prefer storage-enforced uniqueness, conditional update, transaction, or compare-and-set over read-check-write.
- Define conflict behavior for concurrent updates.
- Set deduplication retention beyond the maximum retry and delay window.
- Distributed locks require owner tokens, TTL, renewal, and defined behavior after ownership loss.
- Do not continue irreversible side effects after losing the lock unless the protocol proves safety.

For TTL, leases, windows, scheduling, and retry, define clock source, unit, timezone, expiry boundary, and skew impact.